Updated and rebased.

Will submit around end of day if there's no more comments.

In D79822#2037337, @leonardchan wrote:

@pcc Do you happen to have a list of platforms that you suspect use libgcc and will break with this CFI? If this is a bug compatibility issue, we're thinking that instead of just disabling this for everyone, we should instead disable it for a blacklisted set of targets. So all targets by default would go through this branch except for those that actively crash from this.

*ping* Anything else that should be updated?

*ping*

*ping*

Rebased and formatted.

Rebase and remove __hwasan_shadow_memory_dynamic_address. We don't need to set it anymore.

The non-fuchsia stuff can be split up in a separate patch when ready, but I'll keep it here for now until we're set on the thread handling.

Let me know if these functions should be split up or can land together.

Oh, actually @pcc was right on closer inspection. This is a misunderstanding on my end. So the {{bt:...}}} comes from

In D103564#2806292, @thakis wrote:

this breaks tests: http://45.33.8.238/linux/48401/step_10.txt

// CHECK: #0 {{.*}} in {{.*}}free{{.*}} {{.*}}hwasan_interceptors.cpp

vs

13: #0 0x5647a467e9a0 in free ../../compiler-rt/lib/hwasan/hwasan_allocation_functions.cpp:75:3

need to update the path in that test

In D103845#2804441, @pcc wrote:

This isn't how the output looks on Android. Are you sure this isn't a Fuchsia-specific bug in the output formatting?

Should _LLVM_ENABLE_PIC ON also be added for the multilibs?

Followed up with Roland's suggestion and moved everything relating to the allocation functions.

In D103564#2795287, @mcgrathr wrote:

I think probably the better refactoring here would be to split this file in two: one containing just the allocation functions; and a second with everything else.
On Fuchsia, we'll use the allocation functions but none of the rest of it. So the second whole file could just be under #if !SANITIZER_FUCHSIA.

Update to remove instrumentation on globals. It's likel we may not need the hwasan+relative-vtables multilibs when the next clang roll comes around.

Well, no, I'm afraid it is actually clear that that code does have UB according to the C++ standard. Perhaps you mean that it *shouldn't* have UB, or that Clang should define its behavior despite the standard.

I might agree with you that I don't see the value in using this stronger rule in C++, but I think it would help to understand the problem a little better. I assume this is causing problems for a less trivial test case? Or do you really have code that's relying on that loop not terminating?

Hi all, it looks like this commit led to some unexpected behavior in our build. When compiling something like:

Update to some feedback from first round of reviews. Minor refactoring of code that can be shared between the linux and fuchsia implementations. Still need to discuss refactoring the hwasan threads implementation.

Hi. Looks like this patch might be causing the failure we're seeing on our clang builders (https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-x64/b8847235218143593424):

Ready for reviews. Let me know if I should add other reviewers for the flag/option processing. This shouldn't impact how the experimental flag is used. It's just processing it that's different.

Change the tablegen definition of -f[no-]experimental-relative-c++-abi-vtables from a BoolFOption to two separate flags so we can control the default value of the RelativeCXXABIVTables LangOption more explicitly. This is needed so we can set the default value of this option depending on the target.

I think either this or one of the following two JITLink-related commits (74a96b4c98434e328eeca0afc85dc7053133a7d2, a0162a81b1377331c3e0ebb58ac349b2ffd7b598) might've led to the test failures we're seeing on our clang builders (https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-x64/b8847489160968241440):

Looks like this patch might be leading to the test failure we're seeing on our two-stage-builders (https://luci-milo.appspot.com/p/fuchsia/builders/prod/clang-linux-x64/b8847508232983084096):