Bug 188460 - [CMake] Add ENABLE_UNDEFINED_BEHAVIOR_SANITIZER to make it easier to build with UBSan
Summary: [CMake] Add ENABLE_UNDEFINED_BEHAVIOR_SANITIZER to make it easier to build wi...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-09 17:08 PDT by Don Olmstead
Modified: 2018-08-18 07:35 PDT (History)
10 users (show)

See Also:


Attachments
Patch (2.08 KB, patch)
2018-08-09 17:20 PDT, Don Olmstead
mcatanzaro: review+
ews-watchlist: commit-queue-
Details | Formatted Diff | Diff
ares6 results (3.17 MB, text/plain)
2018-08-13 10:40 PDT, Christopher Reid
no flags Details
Archive of layout-test-results from ews206 for win-future (12.91 MB, application/zip)
2018-08-17 17:34 PDT, EWS Watchlist
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Don Olmstead 2018-08-09 17:08:52 PDT
Make it easier to build with UBSan support https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
Comment 1 Don Olmstead 2018-08-09 17:20:31 PDT
Created attachment 346878 [details]
Patch

Adds ENABLE_UNDEFINED_BEHAVIOR_SANITIZER flag
Comment 2 Michael Catanzaro 2018-08-09 19:37:36 PDT
Comment on attachment 346878 [details]
Patch

Seems fine to me.

Please wait a day before committing in case Konstantin has some comment.
Comment 3 Don Olmstead 2018-08-09 20:11:05 PDT
Comment on attachment 346878 [details]
Patch

(In reply to Michael Catanzaro from comment #2)
> Comment on attachment 346878 [details]
> Patch
> 
> Seems fine to me.
> 
> Please wait a day before committing in case Konstantin has some comment.

K I'll let Konstantin cq+ it if he approves
Comment 4 Fujii Hironori 2018-08-10 01:29:30 PDT
I uploaded the result of UBSan.

https://gist.github.com/fujii/219fd997e13a1d06cfbedb819ef286b1

> ./Tools/Scripts/build-webkit --gtk --release --cmakeargs=-DENABLE_UNDEFINED_BEHAVIOR_SANITIZER=1
> ./Tools/Scripts/run-webkit-tests --gtk --release --no-new-test-results fast/url

Some code is intentionally using undefined behavior.
It seems that you should define ASAN_ENABLED macro.
Comment 5 Konstantin Tokarev 2018-08-10 04:08:45 PDT
Comment on attachment 346878 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=346878&action=review

> Source/cmake/WebKitCompilerFlags.cmake:185
> +        set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fsanitize=undefined")

1. Ideally, when CMAKE_EXE_LINKER_FLAGS and CMAKE_SHARED_LINKER_FLAGS are modified, one should also modify CMAKE_MODULE_LINKER_FLAGS
2. Why not just use ECMEnableSanitizers? [1] At least it makes sense to borrow there ideas, e.g. there must be a reason why they use -fno-optimize-sibling-calls with ubsan as well.

[1] https://github.com/KDE/extra-cmake-modules/blob/master/modules/ECMEnableSanitizers.cmake
https://api.kde.org/ecm/module/ECMEnableSanitizers.html
Comment 6 Michael Catanzaro 2018-08-10 06:47:58 PDT
(In reply to Konstantin Tokarev from comment #5)
> Comment on attachment 346878 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=346878&action=review
> 
> > Source/cmake/WebKitCompilerFlags.cmake:185
> > +        set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fsanitize=undefined")
> 
> 1. Ideally, when CMAKE_EXE_LINKER_FLAGS and CMAKE_SHARED_LINKER_FLAGS are
> modified, one should also modify CMAKE_MODULE_LINKER_FLAGS

Don, you should of course fix ENABLE_ADDRESS_SANITIZER as well, then.

> 2. Why not just use ECMEnableSanitizers? [1] At least it makes sense to
> borrow there ideas, e.g. there must be a reason why they use
> -fno-optimize-sibling-calls with ubsan as well.

No opinion from me on this, except the -DECM prefix on the CMake option is not great.

(In reply to Fujii Hironori from comment #4)
> Some code is intentionally using undefined behavior.

Scary.

> It seems that you should define ASAN_ENABLED macro.

Perhaps, but perhaps undefined behavior should always be avoided.
Comment 7 Jonathan Bedard 2018-08-10 08:58:03 PDT
(In reply to Michael Catanzaro from comment #6)
> ...
> 
> Perhaps, but perhaps undefined behavior should always be avoided.

Completely avoiding all behavior UBSan flags will likely be controversial. As an example, (if I'm remember correctly, been a while since I worked with this) signed integer overflow is undefined behavior according to the C++ standards, but in practice, most compilers DO define this behavior so there are a few spots where we do (or perhaps did) rely on this being defined behavior.
Comment 8 Konstantin Tokarev 2018-08-10 09:05:42 PDT
If we rely on signed overflow anywhere, we must use -fwrapv with GCC and Clang, otherwise this behavior is undefined with these compilers
Comment 9 Michael Catanzaro 2018-08-10 09:06:31 PDT
Konstantin beat me to this by a minute, but I'll post this anyway:

(In reply to Jonathan Bedard from comment #7)
> Completely avoiding all behavior UBSan flags will likely be controversial.
> As an example, (if I'm remember correctly, been a while since I worked with
> this) signed integer overflow is undefined behavior according to the C++
> standards

Yes.

> but in practice, most compilers DO define this behavior so there
> are a few spots where we do (or perhaps did) rely on this being defined
> behavior.

For GCC and Clang this is true only if building with -fwrapv, which we do not use in WebKit:

       -fwrapv
           This option instructs the compiler to assume that signed arithmetic
           overflow of addition, subtraction and multiplication wraps around
           using twos-complement representation.  This flag enables some
           optimizations and disables others.  The options -ftrapv and -fwrapv
           override each other, so using -ftrapv -fwrapv on the command-line
           results in -fwrapv being effective.  Note that only active options
           override, so using -ftrapv -fwrapv -fno-wrapv on the command-line
           results in -ftrapv being effective.

If any of our code assumes twos-complement overflow, I think that would be a bug.
Comment 10 Christopher Reid 2018-08-13 10:40:39 PDT
Created attachment 347015 [details]
ares6 results

Results from running ares6 with UbSan and callstacks enabled for reference.
Comment 11 Yusuke Suzuki 2018-08-14 09:30:47 PDT
I propose adding silence_unsigned_overflow. In JSC, we know the semantics of unsigned overflow, and intentionally use it. While signed overflow is an UB, unsigned is not :)
Comment 12 Konstantin Tokarev 2018-08-14 09:35:09 PDT
AFAIU UBSan doesn't trap on unsigned overflow unless you pass -fsanitize=unsigned-integer-overflow explicitly
Comment 13 EWS Watchlist 2018-08-17 17:34:18 PDT
Comment on attachment 346878 [details]
Patch

Attachment 346878 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/8896636

New failing tests:
imported/blink/transitions/unprefixed-transform.html
legacy-animation-engine/imported/blink/transitions/unprefixed-transform.html
Comment 14 EWS Watchlist 2018-08-17 17:34:29 PDT
Created attachment 347417 [details]
Archive of layout-test-results from ews206 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews206  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Comment 15 Michael Catanzaro 2018-08-18 07:34:40 PDT
Comment on attachment 346878 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=346878&action=review

>>> Source/cmake/WebKitCompilerFlags.cmake:185
>>> +        set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fsanitize=undefined")
>> 
>> 1. Ideally, when CMAKE_EXE_LINKER_FLAGS and CMAKE_SHARED_LINKER_FLAGS are modified, one should also modify CMAKE_MODULE_LINKER_FLAGS
>> 2. Why not just use ECMEnableSanitizers? [1] At least it makes sense to borrow there ideas, e.g. there must be a reason why they use -fno-optimize-sibling-calls with ubsan as well.
>> 
>> [1] https://github.com/KDE/extra-cmake-modules/blob/master/modules/ECMEnableSanitizers.cmake
>> https://api.kde.org/ecm/module/ECMEnableSanitizers.html
> 
> Don, you should of course fix ENABLE_ADDRESS_SANITIZER as well, then.

Still needs CMAKE_MODULE_LINKER_FLAGS (bug #188699)
Comment 16 Michael Catanzaro 2018-08-18 07:35:56 PDT
Comment on attachment 346878 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=346878&action=review

> Source/cmake/WebKitCompilerFlags.cmake:181
> +        WEBKIT_PREPEND_GLOBAL_COMPILER_FLAGS(-fno-omit-frame-pointer)

Put this inside an if (NOT ENABLE_ADDRESS_SANITIZER) so that we don't add it twice if both sanitizers are enabled. (ubsan is the only sanitizer that doesn't conflict with the other sanitizers. If we add more sanitizers in the future, we need to make sure to fail the build if conflicting sanitizers are enabled.)