Reopening with new revision since previous version has been reverted due to my mistake.
Apologies again for that lazy mistake.

Apologies for the original mistake (which was pretty bad), and the very slow response.

Accidentally created a new revision when attempting to update an existing revision.
Was trying to use arc for first time.

The problem is when hwasan detects a fault accessing a value on the stack in Linux.
What I believe happens is:

In D69045#2034976, @jdanek wrote:

In D69045#2031667, @mmalcomson wrote:

(FWIW this particular setjmp can be intercepted in glibc 2.31 -- so hopefully as time goes on this will be less of a problem).

I am the reporter of the linked GitHub issue. Are you saying that if I just built with glibc 2.31, without any change to clang, then I would not see this instance of the setjmp error?

I believe I am on 2.31 already:

In D69045#2030063, @eugenis wrote:

According to https://github.com/google/sanitizers/issues/1244, there is a non-interceptable _setjmp in __libc_start_main that is later jumped to in pthread_exit.
It seems to break this approach.
Any idea what to do? Detect that jmpbuf is not a hwasan jmpbuf and bail out? This is happening at the very end of a thread's life, so hopefully it should not matter that the stack in not untagged.

Ping @pcc -- does this change to remove lazy thread initialisation look OK?

Have addressed raised issues.

I've tried to get this working for Android.

Closing given the allocator fallback feature is not being pursued any more.

If late interposition is no longer a supported use-case, does that apply to the pthread use case as well?
https://reviews.llvm.org/D56038

Now avoid returning a zero tag when tagging is disabled.

Remove some superfluous semicolons that were causing warnings.

Added a test in the hwasan testsuite.

In D68794#1710151, @eugenis wrote:

LGTM
Thank you!
Do you want me to submit this change for you?

In D68794#1706679, @eugenis wrote:

In D68794#1705862, @mmalcomson wrote:

Run prctl syscall for Android, but ignore EINVAL failures.

NOTE: I don't believe this distinguishes between running on a kernel with with the tagged address ABI unconditional or running on a newer kernel or on a kernel with sysctl abi.tagged_addr_disabled=1 (https://android.googlesource.com/kernel/common/+/690c4ca8a5715644370384672f24d95b042db74a/Documentation/arm64/tagged-address-abi.rst)

This is a good point. It appears that PR_GET_TAGGED_ADDR_CTRL works even when abi.tagged_addr_disabled=1, we can use it to tell these two cases apart

Run prctl syscall for Android, but ignore EINVAL failures.