Page MenuHomePhabricator

Add __has_feature(leak_sanitizer)
AbandonedPublic

Authored by fjricci on Jun 14 2017, 9:10 AM.

Details

Summary

Stand-alone leak sanitizer builds are supported with -fsanitize=leak,
adds an attribute for consistency with the rest of the sanitizer attributes.

Event Timeline

fjricci created this revision.Jun 14 2017, 9:10 AM
kcc added a subscriber: kcc.Jun 14 2017, 10:28 AM

I'm not sure about this one.
standalone lsan is a link-time feature only, it doesn't change the compilation, so the argument of consistency doesn't apply.

Currently, the way that we tell users to gate on sanitizer-specific behavior is with __has_feature(foo_sanitizer), as far as I know, it's the only way to do so. LSan provides several API functions for users, ie __lsan_ignore_object. If a user program wants to use these API functions in their program, they need a way to check that LSan is enabled at compilation time (even if LSan doesn't actually modify the compile step). I'm not sure of a better or more consistent way to allow that to happen.

Currently, the way that we tell users to gate on sanitizer-specific behavior is with __has_feature(foo_sanitizer), as far as I know, it's the only way to do so. LSan provides several API functions for users, ie __lsan_ignore_object. If a user program wants to use these API functions in their program, they need a way to check that LSan is enabled at compilation time (even if LSan doesn't actually modify the compile step). I'm not sure of a better or more consistent way to allow that to happen.

Can't you use weak hooks in your code for this purpose?

fjricci abandoned this revision.Jun 14 2017, 11:43 AM

Weak hooks do provide a good solution, abandoning for now (although it may need to be reconsidered if we get a windows LSan port up and running).

fjricci reclaimed this revision.Jun 20 2017, 12:14 PM

As I've looked into this further, I do think we need has_feature(leak_sanitizer) after all. For example, if a user program calls pthread_create() with a custom stack size, leak sanitizer will intercept the call to pthread_create(), and may modify the stack size set by the user (lsan's interceptor for pthread_create calls AdjustStackSize in sanitizer_common). Without has_feature(leak_sanitizer), there's no good way for the user program to account for these sorts of modifications. There are most likely other interceptors which will cause similar issues, this is just the first example I ran into.

rnk edited edge metadata.Jun 20 2017, 12:44 PM

If LSan is a runtime thing, why not use weak hooks or something to detect LSan at runtime instead of using a macro?

fjricci abandoned this revision.Jul 10 2017, 9:47 AM
kcc added a comment.Jul 10 2017, 9:51 AM
In D34210#785828, @rnk wrote:

If LSan is a runtime thing, why not use weak hooks or something to detect LSan at runtime instead of using a macro?

+1

For a run-time-only feature the checking should also be run-time-only (not compile-time)

Yeah, I think that makes sense. Life will get a bit tricky when Windows support gets added and we can't use weak hooks to determine whether LSan is running, but I'm sure there's a way to handle that.

COFF supports weak externals: https://stackoverflow.com/a/11529277/382079. Would it suffice here?

COFF supports weak externals: https://stackoverflow.com/a/11529277/382079. Would it suffice here?

Looks like it could work, thanks.