Still please do not submit if D94210 does not need it.

Please remove and let compiler decide.
ALWAYS_INLINE may confuse future readers

Something is not initialized tihttp://lab.llvm.org:8011/#/builders/74/builds/1834/steps/9/logs/stdio

avoid function local static

update

I assume it's not needed after D93877

We have TEST(SanitizerLinux, ThreadDescriptorSize)
Do you know if it fails on your boxes?

Can we add #include "sanitizer_common/sanitizer_glibc_version.h" into interception_linux.h ?

check-asan complains like thins:

LGTM, I'll accept in a day or so if no other feedback

I don't have strong opinion

Can we embed clang binary location when compiling the program?

I am not sure about this change. For the most of users it's very unlikely to have llvm-symbolizer next to the tested binary. Looks like this just simplifies few tests. I'd rather use usual approach with ASAN_OPTIONS there.

fails here http://lab.llvm.org:8011/#/builders/99/builds/1031

I've chatted about that with @kcc and @eugenis . It seems the problem the patch is trying to solve is less important than regressions. Even with the current state when rare false ODR reports are possible it still useful.
It would be nice with -fsanitize-address-use-odr-indicator, but someone will need to figure-out what to do with few users broken by binary size increase.

I was able to reproduce.

In D92728#2437506, @eugenis wrote:

Don't you want to similarly align down PoisonEnd?

But if this is something that should never happen, as your comment rightly suggests, wouldn't it be better to add an assert()?
The same in the case when PoisonSize < 0 - it should never happen.

In D92521#2434442, @tstellar wrote:

In D92521#2434366, @vitalybuka wrote:

Can you add a test probably in sanitizer_common which reproduces the issue?

The build failure is when building compiler-rt itself, and not in the application trying to use compiler-rt. Should I just create a test mini-sanitizer with one interceptor to demonstrate the problem?

Can you add a test probably in sanitizer_common which reproduces the issue?

It intentionally calls interceptor which will call sigaction_impl where all works is done.

alias change is LGTM, we can try to figure-out how to roll out -fsanitize-address-use-odr-indicator

https://reviews.llvm.org/D55156
So with this patch no code increase but we lose ODR checks.
To preserve checks we need -fsanitize-address-use-odr-indicator but then binary size increase.

What is going to be the default?

I guess another cons was binary size increase? Would you like to run large scale testing on internal Google code?

update

remove unneded change

74536==WARNING: MemorySanitizer: use-of-uninitialized-value

#0 0x7c7b3ed in llvm::Value::setValueName(llvm::StringMapEntry<llvm::Value*>*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/Value.cpp:281:3
#1 0x7c78ec6 in destroyValueName /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/Value.cpp:143:3
#2 0x7c78ec6 in llvm::Value::~Value() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/Value.cpp:104:3
#3 0x7b389e6 in operator() /b/sanitizer-x86_64-linux-fast/build/libcxx_build_msan/include/c++/v1/memory:2122:5
#4 0x7b389e6 in reset /b/sanitizer-x86_64-linux-fast/build/libcxx_build_msan/include/c++/v1/memory:2383:7
#5 0x7b389e6 in ~unique_ptr /b/sanitizer-x86_64-linux-fast/build/libcxx_build_msan/include/c++/v1/memory:2337:19
#6 0x7b389e6 in destroyAll /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/ADT/DenseMap.h:368:25
#7 0x7b389e6 in llvm::DenseMap<llvm::Type*, std::__1::unique_ptr<llvm::PoisonValue, std::__1::default_delete<llvm::PoisonValue> >, llvm::DenseMapInfo<llvm::Type*>, llvm::detail::DenseMapPair<llvm::Type*, std::__1::unique_ptr<llvm::PoisonValue, std::__1::default_delete<llvm::PoisonValue> > > >::~DenseMap() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/ADT/DenseMap.h:754:11
#8 0x7b2f91d in llvm::LLVMContextImpl::~LLVMContextImpl() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/LLVMContextImpl.cpp:125:1
#9 0x7b19cff in llvm::LLVMContext::~LLVMContext() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/LLVMContext.cpp:94:31
#10 0x2561bb6 in main /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:366:1
#11 0x7f93b5e3309a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
#12 0x24e0df9 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/llc+0x24e0df9)

bb93d57ac0d2ecbaaf56dae6268b9e4e1bf32199
19b0dd23e09d1fa902550af206a03b019131bc65

format

Other than file issue, compiler-rt part is LGTM
leaving the rest to @MaskRay

LGTM either way

LGTM with some FIXME explaining that it needs investigation in future