LGTM

LGTM, thank you

I've moved initialization code around a little.

.

LGTM from Linux PoV

LGTM, thanks!

add missing file

I don't like the new Mmap*Shadow functions. The number of different Mmap* functions is growing exponentially with any new feature, let's use flags and/or arguments instead.

LGTM, I'm almost 100% sure this is safe, but I don't remember all the linker quirks around associated sections now.

So far the changes look fine to me.
Let's wait for @kcc, who hates ifdefs, to chime in.

Btw what if getUniqueModuleId returns ""? It may happens for files without external symbols.
I think we need to fall back to non-GCed counters.

LGTM
FTR, http://llvm.org/docs/LangRef.html#associated-metadata mentions that comdat is "recommended".
It would be nice to factor this out into a utility function (create associated global for a global) and use it in asan, too.

This looks fine to me in general. @timshen @etienneb @rnk

lib/sanitizer_common/scripts/gen_dynamic_list.py needs python, and it is used to build asan (and others) runtime library.

LGTM

LGTM

Right! Sorry I missed that.
LGTM.

Looks like you forgot to add the test.

In fact, getShadow() already checks for kParamTLSSize and returns clean shadow if the argument does not fit.
We just need to skip storing argument shadow for such arguments instead of asserting.

LGTM

GCC does not have MemorySanitizer.

There are concerns about this optimization expressed in

https://github.com/google/sanitizers/issues/993

Specifically, it can transform

strcmp("abc\0...undef...undef...", "foobar")

into a similar memcmp() which would observe uninitialized data at the end of the first string.

LGTM, but you probably want to rebase it on top of D51412, instead of including that change in this one.

Please add a test for accessing origin of a va_arg argument in the callee.
Please add a compiler-rt test (or extend an existing one).

LGTM

Looks good for a start.
A test would be nice.

LGTM

I wonder if ProtectMemoryRange in msan_linux.cc needs updating?

Looking at msan.h, 0x000F00000000 is not a valid mapping address:

{0x00000000000ULL, 0x01000000000ULL, MappingDesc::INVALID, "invalid"},

Something's broken.

LGTM, thanks!

LGTM

How interesting, "accept revision" goes to reviewers only, not to the mailing list.

Nice catch!

Sure. Eventually the entire hwasan_interceptors.cc would be under one big ifdef, if things go as planned.

ping

ping

addressed 2 comments

OK. But please mention the fact that runtime library relies on the section entry order in the patch description.

LGTM