[PATCH] D17503: [MSAN] Mark dlerror.cc expected failure for MIPS

[Marcin Kościelnicki via llvm-commits]

koriakin added a subscriber: koriakin.
koriakin added a comment.

I'm dealing with the same thing on PPC64, and I've debugged the issue.  Here's the explanation:

1. dlopen calls to ld.so
2. ld.so fails to load a library
3. ld.so malloc's a buffer for the error message. malloc is external to ld.so, so the usual symbol resolution happens, and our interceptor is called. The memory is poisoned.
4. ld.so memcpy's the error string to the buffer. ld.so includes its own copy of memcpy (for bootstraping), which doesn't go through the usual dynamic linking.  Hence the buffer remains poisoned, even though it was just initialized.
5. dlerror is called. dlerror implementation is directly in libdl.so.
6. dlerror calls strcmp on the above buffer.  Since libdl.so doesn't have bootstrapping issues, this uses normal dynamic binding - calling msan's interceptor.
7. __intercept_strcmp notices the (wrongly) poisoned buffer, and explodes.

As you might have noticed, it works just fine on x86_64.  This is because on x86_64, gcc optimizes the strcmp in libdl.so by converting it to repz cmpsb, avoiding an actual function call.  Since AArch64/MIPS64/PowerPC64 don't have an optimized strcmp, they don't dodge the bullet.  Basically, x86 works by accident, and will stop working if you compile glibc with -O0...

As for fixing this issue - the only thing I can think of is to have a TLS variable __msan_in_libcall that's set for the duration of dlerror and other funny calls, and checked in interceptors, which will then disable all error checking.  Not sure how workable that is.  Thoughts?


Repository:
  rL LLVM

http://reviews.llvm.org/D17503