I do support the unification of the return value, and if no call site is currently care for the actual syscall return value, I'd say, let's make all of them return pointer, nullptr or die. MMAP_FAILED might be a reasonable common ground too, but seems like nullptr is used in many places already and Windows returns NULL on failure, so a bit more unification across platforms here.

Have you noticed any difference in performance? I tried the same back in March I have not noticed any perf gain on the couple of benchmarks. I am merely curious, I think this is a right change to make anyways.

Well, now it is not consistent. Why some types end with T and some not (AllocatorCacheT vs PrimaryAllocator)? Why combined allocator is called Backend and struct Allocator is not called Frontend?

Awesome!

In D48664#1147385, @eugenis wrote:

Good, but please update flag description, too.

How about this name?

• Renamed the flag

In D48142#1142351, @filcab wrote:

In D48142#1142349, @filcab wrote:

Clang still warns:

/Users/filcab/dev/llvm/compiler-rt/lib/asan/asan_allocator.cc:793:18: warning: declaration requires a global constructor [-Wglobal-constructors]
static Allocator instance(LINKER_INITIALIZED);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.

Ah, that's the Asan allocator, which might be bringing something else on. It's probably not about this patch. Sorry for the noise.

• Improve error messages

MSan found a problem here:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/19549/steps/check-llvm%20msan/logs/stdio

In D48141#1132214, @delcypher wrote:

In D48141#1131594, @alekseyshl wrote:

In D48141#1131507, @delcypher wrote:

Isn't this basically https://reviews.llvm.org/D44243 ?

It is! Thanks, missed that one. I'm fine with that one being committed too. Is the explanation on this patch satisfactory?

minor nit: s/on the startup/on application startup/ or s/on the startup/on startup/

I'm fine with either patch. My issue with D44243 is that the reason for the change wasn't provided. The explanation you provide was satisfactory once I read https://github.com/google/sanitizers/issues/194 .
Without reading the github issue it's not so clear what _asan_init-safe means. I'll leave it up to you to decide whether you want the commit message to be clear when read on its own or whether
referencing the GitHub issue is sufficient.

In D48141#1131507, @delcypher wrote:

Isn't this basically https://reviews.llvm.org/D44243 ?

Thanks!

• Die on madvise-ing shadow memory failure.

• rebasing