This is an archive of the discontinued LLVM Phabricator instance.

Don't add sanitizer init function directly into module constructors
AbandonedPublic

Authored by ismailp on Mar 31 2015, 3:49 PM.

Details

Summary

AddressSanitizer creates a function within the module, which calls
__asan_init. This function is then added to the module's constructors.
ThreadSanitizer, and MemorySanitizer, however, add their respective init
functions directly to module constructors. This prevents these
sanitizers be used in certain cases, where module constructor must be
implemented in instrumented object itself. This patch unifies how
sanitizer constructor functions are created, and how init functions are
called across all sanitizers.

Moved checkInterfaceFunction into ModuleUtils.

Diff Detail

Event Timeline

ismailp updated this revision to Diff 23018.Mar 31 2015, 3:49 PM
ismailp retitled this revision from to Don't add sanitizer init function directly into module constructors.
ismailp updated this object.
ismailp edited the test plan for this revision. (Show Details)
ismailp added reviewers: kcc, samsonov, eugenis.
ismailp added a subscriber: Unknown Object (MLST).
kcc edited edge metadata.Mar 31 2015, 4:27 PM

This prevents these sanitizers be used in certain cases,

Can you give an example?

Also, please add tests to test/Instrumentation/*Sanitizer

The change touches 3 sanitizers that have 3 different primary maintainers
It might be simpler to split this patch into several:

  • move checkInterfaceFunction w/o other functionality changes
  • update each of the sanitizers.
lib/Transforms/Instrumentation/AddressSanitizer.cpp
1220

here and below, please use a file-static named constant (e.g. kSanitizerName)

lib/Transforms/Utils/ModuleUtils.cpp
109

You can just print "Sanitizer interface function" to make the code simpler.

ismailp abandoned this revision.Mar 31 2015, 4:50 PM

Thanks for quick response!

In D8754#150169, @kcc wrote:

This prevents these sanitizers be used in certain cases,

Can you give an example?

Yes; Darwin. Dynamic linker is expecting module initializer to be defined within the module itself, otherwise it says:
dyld: initializer function <address> not in mapped image

Also, please add tests to test/Instrumentation/*Sanitizer

Yes, this is clearly forgotten. I was rushing to submit this.

The change touches 3 sanitizers that have 3 different primary maintainers
It might be simpler to split this patch into several:

  • move checkInterfaceFunction w/o other functionality changes
  • update each of the sanitizers.

Makes sense; will do that. I am abandoning this revision, and will submit 2/3 new. Could you please let me know who are primary maintainers for each sanitizer, so that I add correct reviewers?

kcc added a comment.Mar 31 2015, 5:06 PM

Yes; Darwin. Dynamic linker is expecting module initializer to be defined within the module itself, otherwise it says:
dyld: initializer function <address> not in mapped image

Interesting. Does this mean that you are porting tsan/msan to Darwin?
This, especially for msan, could be a great challenge.

The change touches 3 sanitizers that have 3 different primary maintainers
It might be simpler to split this patch into several:

  • move checkInterfaceFunction w/o other functionality changes
  • update each of the sanitizers.

Makes sense; will do that. I am abandoning this revision, and will submit 2/3 new. Could you please let me know who are primary maintainers for each sanitizer, so that I add correct reviewers?

Let's do like this:
asan/common: samsonov@
msan: eugenis@
tsan: dvyukov@
CC me to all of them.

In D8754#150182, @kcc wrote:

Yes; Darwin. Dynamic linker is expecting module initializer to be defined within the module itself, otherwise it says:
dyld: initializer function <address> not in mapped image

Interesting. Does this mean that you are porting tsan/msan to Darwin?
This, especially for msan, could be a great challenge.

Yes, tsan on Darwin. It's mostly working. TLS is the biggest problem. My patches are far from submission quality right now, but I am working on it. Basically;

  • cur_thread() cannot use cur_thread_placeholder, because its storage initialized too late. I will certainly need help with this one. I use malloc to obtain storage, and store this pointer with pthread_setspecific, where key is the finalize key (and that is still a problem :) )
  • Race report doesn't print function name - I think this is easy to fix, although I didn't carefully check yet. I have found TSan's report format is slightly different with ASan's, and ASan report prints function name. Maybe it's really that easy, maybe not...
  • I mostly copied pthread_barrier implementation from FreeBSD, as some tests use this.

After getting TSan to run on Darwin, I can try MSan as well.