yeah, https://reviews.llvm.org/D90188 sounds better to me too.

In D90897#2385929, @MaskRay wrote:

In D90897#2385176, @jhenderson wrote:

In D90897#2379198, @MaskRay wrote:

In D90897#2378385, @jhenderson wrote:

Won't this fail if the PT_LOAD the PT_TLS should be in has a zero size too?

PT_LOAD with p_memsz is invalid on Linux. Attempting to mmap a zero-sized segment will fail.

It is both Linux and FreeBSD (according to rL288808). LLD has removeEmptyPTLoad.

This is an implementation detail that won't necessarily be true for all systems. Kernels could also quite happily ignore zero-sized segments with a trivial piece of code to check the size before calling mmap.

sorry about the breakage... thanks for testing on real hardware!

In D86321#2229537, @vvereschaka wrote:

The test got failed again. I got the following output:

ubuntu@jetson8:~$ ./t.tmp.exe
Testing 29715 symbols.
1ILeeeEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE -> <-0x1.cecececececececececececececep+11983L
Got instead: <-0x1.cecececececececececececececep+11983L>
t.tmp.exe: C:/buildbot/temp/llvm-project/libcxxabi/test/test_demangle.pass.cpp:30001: void testFPLiterals(): Assertion `false' failed.
Aborted (core dumped)

looks like it does not expect trailing >.

Address vvereschaka's comment.

In D77924#2229360, @vvereschaka wrote:

I ran the test directly on our aarch64 board.

In D77924#2228309, @RKSimon wrote:

@enh This is causing a test failure on the windows/aarch64 cross compile bot, please can you take a look:

http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/2267
http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/2267/steps/test-libc%2B%2Babi/logs/FAIL%3A%20libc%2B%2Babi%3A%3A%20test_demangle.pass.cpp

(sorry, didn't see these comments until after i'd git pushed. i've failed to set up gmail filters so i see the mail i need to see without drowning in thousands of mails i don't need to see :-( )

clang-format the new test (but leave the other 30kloc).

In D77924#2089802, @ldionne wrote:

In D77924#2088349, @enh wrote:

In D77924#1977737, @ldionne wrote:

Is it possible to add a test to always trigger this bug?

only if you run with hwasan.

Do the current tests fail under hwasan? If not, please add a test case that fails under hwasan, it's better than nothing.

Add test.

Use actual upper bound.

In D77924#1977737, @ldionne wrote:

Is it possible to add a test to always trigger this bug?

actually, it looks like clang is inlining the code for all the is*_l
functions anyway. you're paying for the indirection on
strcoll_l/strxfrm_l/wcscoll_l/wcsxfrm_l, but no one should be using
those anyway.

honestly, if it was me, i'd keep all these inlines even for current releases: inlining a call to the underlying function saves you a layer of useless cruft at runtime. (the Android "implementations" are just one-liners that drop the extra argument and call the underlying function, just like these inlines.)

i assume the idea here is "all libc++ mutexes are covered by RAII anyway, so there's no value to the error checking"?

yeah, we always used the low numbers internally.

not really though --- i think you're getting that from libgcc. so
although short term you don't need to add this stuff to compiler-rt to
test, it will be necessary for anyone not using libgcc. (like us, at
some point in the future.)