IIRC, print_summary=false override was added to UBSan to keep its output more terse, and also to avoid essentially duplicating the information from the "runtime error" line. If the current maintainers agree that it makes sense to print summary for consistency, I have no objections.

Looks like this code has been removed in https://reviews.llvm.org/D57609, but I'm not sure the removal is correct (added a comment in that thread).

Ugh, too bad the original commit didn't provide any rationale, but here's my guess based on reading the source code:

Note that llvm-symbolizer (or another tool that uses this library) can be invoked with the relative path (e.g. cd /tmp/dir; llvm-symbolizer foo).

That is, even if we want to add this check, it should be closer to the call site, where we know for sure we're demangling the variable name.

I am not sure, but IIRC somewhere we depend on the ability of __cxa_demangle to demangle the type names.

LGTM. Feel free to submit after addressing a couple of comments below.

LGTM

LGTM with a nit below.

LGTM

Please investigate this issue in more details. "There might be some leak in getpwnam_r" is not a good enough reason to exclude this test on MIPS (note that it also runs for ASan, TSan, MSan, not just for LSan).

Cool, great to see this coming. I'll let Kuba sign this off.

LGTM

... that is, make weak bool DisableReexec() { return false; } and override it with function returning true in unit tests.

This is really unfortunate. I also don't like adding the runtime flag for the sake of TSan unit test. Why can we call DisableReexec() from ASan unit tests, but not from TSan ones? The former also use static runtime on OS X?

This was fixed recently, please update.

LGTM after addressing one minor comment below. Thanks!

LGTM

LGTM, thank you!

Looks mostly good, thank you for working on this.

LGTM with a nit. Thanks!

LGTM

LGTM with a nit. Thanks!

LGTM

LGTM

LGTM

LGTM. Thank you for fixing this!

We use __BIG_ENDIAN__ and __LITTLE_ENDIAN__ macro in a few places in sanitizers. Let's update all these use cases to a more portable form for consistency.

LGTM

Yes, this would definitely be a better solution.

I think it's reasonable to make an assumption that we're intercepting strlen(), and the REAL() version works faster. Depending on the order of inclusion is not nice, for sure.

Um, no, let's follow the strategy we use for other macros here and always define SANITIZER_MIPS, SANITIZER_MIPS64 and SANITIZER_MIPS32 to either 1, or 0.

I don't think this change is correct. E.g. in dwarfdump-test.elf-x86-64 symbol "main" has address 0x400540 and size 0x24, which means that 0x400564 does *not* belong to this function.

Submitted as r262678.

LGTM

LGTM

LGTM

I'm somewhat worried about the performance implications of this. IsAccessibleMemoryRange is a syscall after all, not sure it would be nice to call it on every malloc/free. We do run non-trivial operations on these calls though, like collecting stack traces.

LGTM

LGTM

LGTM after fixing a bug below.

LGTM

Looks reasonable (yet sad).

This test checks that dlerror() unpoisons the string it returns. glibc is indeed not instrumented, so some implementations could trigger false positives by calling strcmp() on internal strings are not known to be fully initialized.

Instead of writing different code for x86 and MIPS, can you just make sure that you get a SHMLBA-aligned address?

LGTM

LGTM

LGTM

LGTM

LGTM

Please add a test case for this (probably to test/Driver/fsanitize.c).