LGTM, but please wait for a couple of days in case others wish to review

It's similar to https://reviews.llvm.org/D137604

Thanks @aaron.ballman. I don’t have commit access, can you land this patch for me? Please use “Yabin Cui yabinc@google.com” to commit the change.

LGTM. I have verified that it solves the problem of booting hwasan Android build.

Remove unrelated space change.

Thanks for the fix! I have verified that it fixes tests broken by using AA.

I have filed an internal bug. Not sure when it will be available.

when I create a buildbot for Android, covering the sanitizers, will I have to disable ASRL?

I don't know other sanitizers. But as in this patch, tsan will do it for you.

That is precisely my point about Android/LLVM not being a toy project any more.

I never intend to say Android/LLVM doesn't involve security issue. But for tsan, as it consumes much more memory and runtime slowdown currently, I think no one intend to ship it on product.

But I want us to start thinking about the bigger picture here very soon. It'd also be good if Google could setup up a buildbot on Nexus devices.

We don't have Android/LLVM buildbot now. But I think it is nice to have. srhines@ and danalbert@ should be the right people to talk to.

At Diff1 of this patch, I made it Android specific. And zatrazz recommended
to use VReport() instead of Report() to avoid breaking tests. It doesn't break tests any more when I run make check-tsan.

sorry, I commented on the wrong patch.

At Diff1 of this patch, I made it Android specific. And zatrazz recommended
to use VReport() instead of Report() to avoid breaking tests. It doesn't break tests any more when I run make check-tsan.

ping?

Replace Report() with VReport(), and enable the patch on aarch64.

That patch is reverted because of breaking aarch64 tests. I tried to fix that in http://reviews.llvm.org/D18378, but I think reviewers prefer to limit the change on Android platform. And whoever wants to extend the platforms disabling randomized virtual space can test on the extended platforms.

I applogize for not testing tsan patches well before uploading them to llvm. I will do my best to
test them on other platforms as well as Android. I didn't revert the patch because I think fixing
broken patches instead of reverting them is the first choice. But thanks for reverting it as I
didn't fix it in time. I will upload the patch to make it Android specific soon.

Thanks for reminding. I have tested on x86_64 (by enabling personality(ADDR_NO_RANDOMIZE) on x86_64).

remove change in tsan_platform_linux.cc

Fix mutex_cycle2.c.

This patch is uploaded because I misunderstood kHeapMem as mapped area. And the correct fix has been submitted in http://reviews.llvm.org/D18003.

Add comment.

Disable randomized address space only for aarch64.

not android specific, I have updated in SUMMARY.
Done checking real heap space.

Limit columns to < 80.

Check if real heap space matches expectation before reexec.

As recommended by dvyukov, I find that we can use personality(ADDR_NO_RANDOMIZE) to disable randomized virtual address space. The patch is uploaded at http://reviews.llvm.org/D18003

Sorry for not updating this so long, I was struggling with other stuff.
I don't understand "these sources are outdated, the AArch64 part is not like that any more for a good number of months." When I downloaded the latest linux kernel, the code of arch/arm64/mm/mmap.c is not changed:

profiling results on N5X(aarch64) as below:
mini_bench_local
without tsan: 2.50s
tsan before: 131s
tsan after change: 138s

I think using uptr mapping[256]; is a better solution to remove current complex logic.

use kHeapMemBeg + kHeapMemSize for efficiency.

Done. I didn't add 42-bit version because I don't have a machine to test it.

Add support for 42-bit aarch64.

I only tested this on android with 39-bit aarch64 platform. Let me know if it breaks on other 39-bit aarch64 platforms, or if we have other ways to make things work.

Sorry, I missed two lines when committing http://reviews.llvm.org/D15301. I uploaded the fix in http://reviews.llvm.org/D15301.
I think if !thr->is_inited, it means __tsan_thread_start_func()->ThreadStart() is not called, and I think we shouldn't access
fields in ThreadState as it is not inited. Please let me know if my understanding is wrong.

It works. Thanks!

Abandon this, as it has been split.

Update based on review comment.

@dvyukov, review this again?