This is an archive of the discontinued LLVM Phabricator instance.

[ubsan] Add support for reporting diagnostics to a monitor process
ClosedPublic

Authored by vsk on Jun 21 2018, 10:58 AM.

Details

Summary

Add support to the ubsan runtime for reporting diagnostics to a monitor
process (e.g a debugger).

The Xcode IDE uses this by setting a breakpoint on ubsan_on_report and
collecting diagnostic information via
ubsan_get_current_report_data,
which it then surfaces to users in the editor UI.

Testing for this functionality already exists in upstream lldb, here:
lldb/packages/Python/lldbsuite/test/functionalities/ubsan

Apart from that, this is ninja check-ubsan clean.

Diff Detail

Event Timeline

vsk created this revision.Jun 21 2018, 10:58 AM

Does check-asan work?

It would be nice to test major xcode/lldb expectations here.

lib/ubsan/ubsan_monitor.cc
54

why do you need this?

Thanks, Vedant! This looks good to me.

There's some tests in LLDB, https://github.com/llvm-mirror/lldb/tree/master/packages/Python/lldbsuite/test/functionalities/ubsan that are testing this. But it should be possible to write a test in compiler-rt as well, see https://github.com/llvm-mirror/compiler-rt/blob/master/test/tsan/Darwin/debug_external.cc. But if that turns out to be too much work, I'm okay with just the LLDB test.

vsk updated this revision to Diff 152357.Jun 21 2018, 12:00 PM

Does check-asan work?

Yes.

it should be possible to write a test in compiler-rt as well

I've added test/ubsan/Misc/monitor.cpp.

lib/ubsan/ubsan_monitor.cc
54

This is a relatively noninvasive way of making sure the text of diagnostics can't begin with a lowercase letter. I'll add a comment.

vitalybuka added inline comments.Jun 21 2018, 1:03 PM
lib/ubsan/ubsan_monitor.cc
54

Thanks. That's clear from the code.
I am rather curios why it's important. Is this always upper case for messages from other components passed to monitor?

vsk added inline comments.Jun 21 2018, 1:18 PM
lib/ubsan/ubsan_monitor.cc
54

Oh, good question. I'm not sure how the other sanitizers handle capitalization.

W.r.t ubsan integration into Xcode, I was simply asked to make diagnostics start with proper capitalization during internal review. Because of loose coupling between compiler-rt and Xcode, it was more convenient to do the capitalization here, although it would be cleaner to move this into Xcode.

vitalybuka added inline comments.Jun 21 2018, 5:31 PM
lib/ubsan/ubsan_monitor.h
36

I'd prefer interface consistent with similar one from TSAN:
__tsan_on_report(void *report) {

__tsan_get_report_loc(report.....
__tsan_get_report_loc_object_type(report.....

}

Also this will avoid having state set by RegisterUndefinedBehaviorReport

vsk added inline comments.Jun 21 2018, 5:55 PM
lib/ubsan/ubsan_monitor.h
36

Point taken, it would be a bit simpler this way. However, we can't make this change because it would break debuggability of code compiled with Xcode 9.

vitalybuka added inline comments.Jun 21 2018, 5:58 PM
lib/ubsan/ubsan_monitor.h
36

Does Xcode 9 works for tsan?

vsk added inline comments.Jun 21 2018, 6:07 PM
lib/ubsan/ubsan_monitor.h
36

Are you asking if IDE diagnostics for tsan issues found in a binary compiled with Xcode 9, work when running under Xcode (9+K)? I'm not sure. Generally we try to make it possible to debug old binaries.

vitalybuka added inline comments.Jun 21 2018, 6:12 PM
lib/ubsan/ubsan_monitor.h
36

I am confused. Could you please elaborate why change in non existing yet API will break code compiled with Xcode 9?

To clarify, I propose to have:

__ubsan_on_report(void *report) {
    __ubsan_get_report_loc(report.....
    __ubsan_get_report_other_stuff(report.....
}
...
similar to tsan
kubamracek added inline comments.Jun 21 2018, 6:12 PM
lib/ubsan/ubsan_monitor.h
36

Yes, Xcode 9 supports TSan and UBSan. I think we really need to keep the interface as it is, at least for this initial commit. Changes in the interface should then try to be as compatible as possible. Every time TSan's debugging interface changed, we did that in a backwards-compatible manner (debugging old binaries works), and forwards-compatible way as well (worst case is you'll miss some data in the report).

vitalybuka added inline comments.Jun 21 2018, 6:16 PM
lib/ubsan/ubsan_monitor.h
36

Not sure I understand the answer.
Does Xcode 9 already expects ubsan_on_report and ubsan_get_current_report_data as is?

vsk added inline comments.Jun 21 2018, 6:17 PM
lib/ubsan/ubsan_monitor.h
36

Yes, I'd like to upstream the compiler-rt support. One benefit to the community is that downloadable open-source toolchains will become compatible with Xcode's ubsan support.

vitalybuka accepted this revision.Jun 21 2018, 6:19 PM
vitalybuka added inline comments.
lib/ubsan/ubsan_monitor.h
36

Thanks. I see now.

This revision is now accepted and ready to land.Jun 21 2018, 6:19 PM
This revision was automatically updated to reflect the committed changes.
Herald added a subscriber: Restricted Project. · View Herald TranscriptJun 22 2018, 10:26 AM

This seems to have broken the Windows build.
vc:\b\slave\sanitizer-windows\llvm\projects\compiler-rt\lib\ubsan\ubsan_interface.inc(55): error C2065: '__ubsan_on_report': undeclared identifier
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/30528/steps/build%20compiler-rt/logs/stdio

vsk added a comment.Jun 22 2018, 12:55 PM

Taking a look now.

thakis added a subscriber: thakis.Jun 25 2018, 1:46 PM
thakis added inline comments.
test/ubsan/TestCases/Misc/monitor.cpp
3

This test fails on Windows: https://logs.chromium.org/v/?s=chromium%2Fbb%2Ftryserver.chromium.win%2Fwin_upload_clang%2F361%2F%2B%2Frecipes%2Fsteps%2Fpackage_clang%2F0%2Fstdout

$ ":" "RUN: at line 1"
$ "C:/b/rr/tmpnnvph5/w/src/third_party/llvm-bootstrap/./bin/clang.exe" "-w" "-fsanitize=bool" "C:\b\rr\tmpnnvph5\w\src\third_party\llvm\projects\compiler-rt\test\ubsan\TestCases\Misc\monitor.cpp" "-o" "C:\b\rr\tmpnnvph5\w\src\third_party\llvm-bootstrap\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\monitor.cpp.tmp"
# command output:
clang_rt.ubsan_standalone-x86_64.lib(ubsan_monitor.cc.obj) : error LNK2005: __ubsan_on_report already defined in monitor-c1dd53.o
   Creating library C:\b\rr\tmpnnvph5\w\src\third_party\llvm-bootstrap\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\monitor.cpp.lib and object C:\b\rr\tmpnnvph5\w\src\third_party\llvm-bootstrap\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\monitor.cpp.exp
monitor-c1dd53.o : warning LNK4217: locally defined symbol __std_terminate imported in function "int `public: static unsigned __int64 __cdecl std::char_traits<char>::length(char const * const)'::`1'::dtor$2" (?dtor$2@?0??length@?$char_traits@D@std@@SA_KQEBD@Z@4HA)
monitor-c1dd53.o : warning LNK4217: locally defined symbol _CxxThrowException imported in function "public: void __cdecl std::ios_base::clear(int,bool)" (?clear@ios_base@std@@QEAAXH_N@Z)
C:\b\rr\tmpnnvph5\w\src\third_party\llvm-bootstrap\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\monitor.cpp.tmp : fatal error LNK1169: one or more multiply defined symbols found
# command stderr:
clang.exe: error: linker command failed with exit code 1169 (use -v to see invocation)

I'll note that no other ubsan test includes iostream. clang tests at least try to not use system headers; I'm guessing this is probably true for compiler-rt tests as well?

If there's no quick fix, please revert while investigating to get the build back to green for now.

(That bot uses msvc2017; the llvm buildbot bots maybe use something older.)

kubamracek added inline comments.Jun 25 2018, 1:50 PM
test/ubsan/TestCases/Misc/monitor.cpp
3

@vsk, I guess this is because of the weak definition of __ubsan_on_report. Should we just mark the test as UNSUPPORTED: win32?

thakis added inline comments.Jun 25 2018, 5:07 PM
test/ubsan/TestCases/Misc/monitor.cpp
3

Looks like the test got disabled on win in r335523, thanks!