Gave AdjustFd a more descriptive name.

LGTM

LGTM

LGTM
Does it mean that either --icf=none or odr-indicators must be used to avoid false positives?

LGTM
consider keeping a CHECK_GE(end, beg)

LGTM

I've reverted both commits.
The aosp build I've tried is broken in a different way.
I'll reapply the changes once the bot can handle them.

And of course, this broke the android O bot:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/builds/17949

LGTM

LGTM

LGTM

In D55554#1328211, @evgeny777 wrote:

Addressed some of review comments
Unfortunately I don't know how to use memset from __hwasan_memset, given this comment in hwasan.cc

// ACHTUNG! No system header includes in this file.

Hmm, this is not enough, you also need to update instrumentation in HWAddressSanitizer::getHwasanThreadSlotPtr

Added newline at the end of the error message.

A follow-up to this change:
https://reviews.llvm.org/D55587

LGTM, thanks.

LGTM

We should do the same thing in kernel mode, I think. Either way memintrinsic checking will require changes on the kernel side. @andreyknvl

In fact, I changed my mind - let's do __hwasan_memset.
Tag checking in memset is part of software emulation; as such, it belongs in libclang_rt.hwasan, and not in any system library.

Yes, I think so.

I think I prefer regular memset to hwasan_memset.
hwasan variants can be slightly faster because they don't need to check that the address is not a shadow address (from stack tagging), but that is probably not a big deal.
Also the hardware implementation will definitely not have (or need) __hwasan_memset.

LGTM

LGTM

LGTM

Linux linkers won't include a member of an archive only because it resolves a weak symbol, so in your example the answer is none.

How about "Static linking of executables is not supported"?

LGTM

I've added original contributors of the private-alias thing to double check that we are not breaking any assumptions by doing this.

Sorry for the delay.
This is wrong, static linking is NOT supported.
You could be confusing it with static linking of asan runtime library to an executable - that is and has always been the default.

LGTM

Would turning asan operator new/delete into weak symbols help?

The new operator is already a weak symbol in libcxx, so it looks like an ODR violation, doesn't it?

Looks fine to me.

Our malloc definition is weak already, this will only change new/delete to match.

Would turning asan operator new/delete into weak symbols help?

LGTM

LGTM with nit

LGTM

Users will hate these reports.
LGTM with comments

LGTM

LGTM

Is this needed for the clients of that out-of-process allocator inspection thing? Could it be a separate library that links asan allocator in out-of-process mode, but not the rest? Otherwise you are adding a mode of execution to ASan when there is no shadow mapping, and now that's something that everyone else have to keep in mind.

LGTM

LGTM

Yes, thanks you! LGTM

You are right, initial-exec TLS would work for hwasan and msan. It would cost about 2 instructions and 1 load per function, compared to the fixed slot. Not great, but tolerable.

Yes, this is much better!
LGTM

The same failure as MaskRay describes has kept sanitizer-linux bot red for several days now:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/17090

@cryptoad
TLS_SLOT_TSAN is used in scudo, tsan and hwasan. AFAIK we don't yet depend on binary compatibility for either.

I agree, now that -fsanitize-minimal-runtime does not enforce that _only_ minimal runtime is used, it makes sense to split it per-sanitizer, with -fsanitize-minimal=<name>.

LGTM

LGTM

Or, rather, define something like common_cxxflags in test/lit.common.cfg and apply them in all sanitizer tests.
This script should not edit compilation flags.

Could you change config.clangxx in test/asan/lit.cfg instead?

Please rename the remaining FD's.
LGTM then.