Page MenuHomePhabricator

[NFC][Sanitizer] Change "return type" of INTERCEPT_FUNCTION to void
ClosedPublic

Authored by yln on Apr 25 2019, 1:27 PM.

Details

Summary

This temporary change tells us about all the places where the return
value of the INTERCEPT_FUNCTION macro is actually used. In the next
patch I will cleanup the macro and remove GetRealFuncAddress.

Diff Detail

Repository
rL LLVM

Event Timeline

yln created this revision.Apr 25 2019, 1:27 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptApr 25 2019, 1:27 PM
Herald added subscribers: llvm-commits, Restricted Project, kubamracek. · View Herald Transcript
yln marked 2 inline comments as done.Apr 25 2019, 1:37 PM
yln added inline comments.
compiler-rt/lib/asan/asan_interceptors.h
127 ↗(On Diff #196717)

You said this protects against "double interception"?
If this works as expected, then should we push it up into INTERCEPT_FUNCTION?
Why do we only protect against "double interception" in ASan and MSan, but not the other sanitizers?

My best guess is that this has been obsolete for a while.

134 ↗(On Diff #196717)

Note that this is different from above, it's essentially: (!REAL(name) || !REAL(name))

yln edited the summary of this revision. (Show Details)Apr 25 2019, 1:40 PM
vitalybuka added inline comments.Apr 25 2019, 2:15 PM
compiler-rt/lib/interception/interception_linux.h
37 ↗(On Diff #196717)

why?

compiler-rt/lib/msan/msan_interceptors.cc
1247 ↗(On Diff #196717)

why you don't want to keep this comparison inside of INTERCEPT_FUNCTION_LINUX_OR_FREEBSD?

vitalybuka added inline comments.Apr 25 2019, 2:17 PM
compiler-rt/lib/asan/asan_interceptors.h
127 ↗(On Diff #196717)

Yes, I would like to put this into INTERCEPT_FUNCTION
however maybe VReport is not available in all users

yln marked 3 inline comments as done.Apr 25 2019, 2:38 PM
yln added inline comments.
compiler-rt/lib/asan/asan_interceptors.h
127 ↗(On Diff #196717)

Got it. I will try to make this nicer/more uniform in follow-ups.

compiler-rt/lib/interception/interception_linux.h
37 ↗(On Diff #196717)

So the compiler tells me all the places where the return value is used. I want to commit it like this so that the bots compile it for all the configurations that I can't test locally.

compiler-rt/lib/msan/msan_interceptors.cc
1247 ↗(On Diff #196717)

It prevents the cleanups in [tsan_interceptors.cc] (see https://reviews.llvm.org/D59504).

We can not use TSAN_INTERCEPT to get setjmp addr,
because it does &setjmp and setjmp is not present in some versions of libc.

vitalybuka accepted this revision.Apr 26 2019, 9:37 AM
This revision is now accepted and ready to land.Apr 26 2019, 9:37 AM
This revision was automatically updated to reflect the committed changes.
rnk added a subscriber: rnk.Apr 30 2019, 1:17 PM
rnk added inline comments.
compiler-rt/trunk/lib/asan/asan_interceptors.h
125–127

I don't think this change is functionally correct on Windows. The interception mechanism on Windows is based on hotpatching, so the address comparison will always fail. This has created a minor regression in that now any asanified binary run with ASAN_OPTIONS=verbosity=1 emits "failed to intercept *" for every asan-specific interceptor. Checking the reteurn value was the correct thing to do for Windows. I want to revert this, WDYT?

vitalybuka added inline comments.Apr 30 2019, 1:27 PM
compiler-rt/trunk/lib/asan/asan_interceptors.h
125–127

Oh, I forgot about windows that didn't noticed that the check moved from LINUX_OR_FREEBSD into everything.
I guess it should be fine to revert it. but this needs to be reverted as well D61205
I guess yln@ is in different timezone.

yln marked an inline comment as done.Apr 30 2019, 1:53 PM
yln added inline comments.
compiler-rt/trunk/lib/asan/asan_interceptors.h
125–127

Can we try to fix this for Windows instead of reverting altogether. I will provide a patch asap.

rnk added inline comments.Apr 30 2019, 1:59 PM
compiler-rt/trunk/lib/asan/asan_interceptors.h
125–127

The revert became rL359611. I can help review any relanding, but I'm not sure why we'd want INTERCEPT_FUNCTION to return void in the first place, it seems best to have some way to signal failure. Interception is inherently quite prone to failure, and a return value seems like the best, most portable way to signal that.