(rebase)

updated

updated diff

Set cmake ndk-version variable

updated

Use the libc++_shared.so under sysroot rather than searching for it.
(In the new NDKs, there are a bunch of libc++_shared.so for different archs)

May I ask you to move ANDROID_HAS_ELF_TLS and ANDROID_HAS_ELF_TLS into a separate patch so we can keep ndk upgrade only to see how it works for the bot?

updated

In D89924#2348784, @vitalybuka wrote:

actually I see a lot of test failing with v21 on 93953d411a0fc240e10237fea34aaff43e8f0ff5 on x86 emulator

updated

Removed the over-align hack, because D89924 is upgrading ndk to 21.

updated to use the right API, depending on the device and use libc++

rebase

updated

rebase

In D89615#2345448, @vitalybuka wrote:

In D89615#2345430, @srhines wrote:

In D89615#2345350, @jyknight wrote:

In D89615#2342857, @vitalybuka wrote:

Why we can't just switch to elf TLS?

It seems to me that ideally the NDK clang should be defaulting to -fno-emulated-tls for android with a new enough target platform version, and should also be defaulting to use lld. I think that's been the plan for a while -- do you know if it's going to actually happen soon?

That might then make some of these changes unnecessary.

@danalbert to make sure I don't mix this up. https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r22 shows that NDK r22 (which is going to beta soon) does indeed change the default linker to LLD. For TLS, this is indeed sensitive to target API, and Android will still be targeting those older APIs for quite some time (so we can't just remove support for them).

if I read this correctly we can switch Android to lld unconditionally right now now?

<diff>

updated diff

In D89251#2344005, @vitalybuka wrote:

The patch as is still fails with emulator about 71 tests.

Were all these 71 tests from check-lsan? I was planning on letting D89615 go in first, then this patch. (Otherwise, this patch would have to be submitted with LSAN-on-Android still disabled.)

updated diff

In D89615#2342857, @vitalybuka wrote:

Why we can't just switch to elf TLS?

updated diff

updated diff

add test

For arm(64), also need to overalign the TLS segment if tests run with ELF-TLS

updated

In D89251#2333846, @vitalybuka wrote:

I recommend to extract smaller patches which can be landed separately.

In D89251#2333843, @vitalybuka wrote:

A lot of tests fails like:

/usr/local/google/home/vitalybuka/src/llvm.git/llvm-project/compiler-rt/test/sanitizer_common/android_commands/android_compile.py  /usr/local/google/home/vitalybuka/slow/bbot/llvm_build64/bin/clang  --driver-mode=g++ -stdlib=libstdc++ -fsanitize=address -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer -fno-optimize-sibling-calls -gline-tables-only  -pie -fuse-ld=gold --target=i686-linux-android --sysroot=/usr/local/google/home/vitalybuka/slow/bbot/android_ndk/standalone-i686/sysroot -B/usr/local/google/home/vitalybuka/slow/bbot/android_ndk/standalone-i686 -fuse-ld=lld  -shared-libasan -O1 -fsanitize-address-use-after-scope /usr/local/google/home/vitalybuka/src/llvm.git/llvm-project/compiler-rt/test/asan/TestCases/use-after-scope-nobug.cpp -o /usr/local/google/home/vitalybuka/slow/bbot/compiler_rt_build_android_i686/test/asan/I386AndroidConfig/TestCases/Output/use-after-scope-nobug.cpp.tmp &&  /usr/local/google/home/vitalybuka/slow/bbot/compiler_rt_build_android_i686/test/asan/I386AndroidConfig/TestCases/Output/use-after-scope-nobug.cpp.tmp
WARNING: linker: /data/local/tmp/Output/usr/local/google/home/vitalybuka/slow/bbot/compiler_rt_build_android_i686/test/asan/I386AndroidConfig/TestCases/Output/use-after-scope-nobug.cpp.tmp: unsupported flags DT_FLAGS_1=0x8000001

CANNOT LINK EXECUTABLE "/data/local/tmp/Output/usr/local/google/home/vitalybuka/slow/bbot/compiler_rt_build_android_i686/test/asan/I386AndroidConfig/TestCases/Output/use-after-scope-nobug.cpp.tmp": unknown reloc type 14 @ 0xa8d63390 (638)
Aborted 
Aborted

rebase

updated diff

updated diff

Updated diff.
Also included the previously reverted patch.

In D89251#2327777, @dmajor wrote:

The build bot is happy with Diff 6! \o/

In D89251#2326637, @dmajor wrote:

[EDIT: This is specific to the armv7-linux-android target]

updated diff

> What about only doing the compilation? That shouldn't require any real hardware, right?

updated diff

In D89251#2326121, @dmajor wrote:

Latest errors: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=318424891&repo=ash&lineNumber=23010

Updated diff:

• use uptr instead of size_t
• only weak-decl for pre-21 API

Move weak decl to header so that it'll be available to users.

In D85927#2325516, @dmajor wrote:

In D85927#2325276, @oontvoo wrote:

Thanks for the report!

In D85927#2325138, @dmajor wrote:

This caused a build break in our compiler-rt build for Android: use of undeclared identifier '__interceptor_memalign'

Are you also building with API 16? (From your second comment)

Yes, that's right. The memalign error is still present after D89251.

updated diff

In D89251#2325571, @eugenis wrote:

This looks wrong. Api level has nothing to do with compile-time support for TLS, and thread-properties API is used with runtime detection (through a weak symbol).

Thanks for the report!

remove use_globals=0 from tests

Make test set use_global=1 for Android and add warnings if use_global is turnt off.

rebase

updated diff

updated diff

Updated diff

updated per review comments

Ah, the issue here was that lit.local.cfg , which was supposed to detect if lbr-tests are runnable, didn't use the right arguments . I've updated it and the test should now be skipped on unsupported kernels/architectures..

More clean up.

(minor cleanup)

Reduce wait time to 5ms. (not really meaningful - we just use this as a way to prevent unrolling)

reduce wait time

Updated a few tests to work on Android.

In D87754#2278447, @vitalybuka wrote:

Maybe this is a prove that not all registers fetched.
How exactly this fails?