In D144057#4179643, @nickdesaulniers wrote:

In D144057#4166558, @melver wrote:

Do the KASAN tests in the kernel pass (need to use -next, mainline is currently broken)? Wondering how we can double check there are no new false positives nor false negatives.

How do I run those?

Simplify assert.

Pinging @eugenis @fmayer @pcc who may have more recently touched ASan/HWASan.

In D144677#4149483, @dvyukov wrote:

The code looks sane to me. But I never looked at this part of the code before.
Wonder if this also fixes debug info?

Update dependency

Move existing tests only.

In D144471#4142299, @MaskRay wrote:

I don't think we want more diagnostic levels. The warning is not fatal, it's just that some users use --fatal-warnings to upgrade warnings to errors.
If this warning is annoying under --fatal-warnings, we can think of message(...). But right now, it seems appropriate for the user to be aware of the problem and discard .llvm_addrsig by themselves.
(I have more notes in https://maskray.me/blog/2020-11-15-explain-gnu-linker-options )

I just discovered that removing .llvm_addrsig (seen that done elsewhere, too) also resolves the issue.

Make Driver test check that cc1 doesn't receive flag if not required.

This is currently more an RFC - there might be other side-effects not yet accounted for, so please review carefully.

Thanks!

Move AsmPrinter LEB128 helpers to AsmPrinter.cpp and use them.

Don't pretend constant accesses are atomic if the function is "covered", so save on space.

Reworked some things to make it more efficient in the presence of constant data accesses.

Make it more efficient by ignoring both non-shared and non-mutable addresses.

In D142982#4093842, @dvyukov wrote:

We also discussed that msan/asan shadow accesses need to be ignored.
MSan accesses can lead to false positives, ASan just to unnecessary checking.
It can also make sense to exclude accesses to global const objects.

Thanks!
I'll land this for you.

Minor comments below. Otherwise LGTM.

Only skip setting weak linkage if function is defined in module.

In D140582#4040513, @Peter wrote:

In D140582#4040428, @melver wrote:

@ Peter, are you able to commit this yourself, or should we commit it for you?

Sorry but I think you got the wrong Peter. I never worked on tsan before:)

@ Peter, are you able to commit this yourself, or should we commit it for you?

Also update commit message to say something about "mem transfer" intrinsics.