android / ndk

The Android Native Development Kit
1.99k stars 257 forks source link

[BUG] armv7a + simd ld.lld segmentation fault during linking NEON code #1248

Closed arturbac closed 2 years ago

arturbac commented 4 years ago

Description

With ndk r-21.* clang ld.lld started to fail generating neon instructions when source code uses neon intrinsics for armeabi-v7a. With ndk r-20 there is no problem and no segmentation fault during linking stage. ndk-r21 still generates proper code for armv-8a

  1. Running pass 'Function Pass Manager' on module 'ld-temp.o'.
  2. Running pass 'ARM Instruction Selection' on function '@_ZN4conv27yCrCb2rgb_aarch64_yps1_chs1E18yuv_data_info_tmplIPKSt4byteEPhj'

    0 0x0000000000e59f92 (/opt/android-sdk/ndk/21.1.6352462/toolchains/llvm/prebuilt/linux-x86_64/bin/ld.lld+0xe59f92)

    1 0x0000000000e5a727 (/opt/android-sdk/ndk/21.1.6352462/toolchains/llvm/prebuilt/linux-x86_64/bin/ld.lld+0xe5a727)

    2 0x00007f0ddea1b0b0 __restore_rt (/lib64/libpthread.so.0+0x130b0)

    3 0x000000000143b92d (/opt/android-sdk/ndk/21.1.6352462/toolchains/llvm/prebuilt/linux-x86_64/bin/ld.lld+0x143b92d)

    4 0x00007ffc234315f0

    clang++: error: unable to execute command: Segmentation fault (core dumped) clang++: error: linker command failed due to signal (use -v to see invocation) ninja: build stopped: subcommand failed.

Environment Details

I attached linking output with seg fault and preprocessed source code of function mentioned in linker fault. I cannot narrow down more what causes seg fault than preprocessed source file. linking_fault.txt

yuv_to_rgb_alligned.cc.txt

DanAlbert commented 4 years ago

I think clang usually generates a tarball of the repro case for a crash. Does LLD not do that? If you have that, that'll help. Otherwise, it looks like we have the preprocessed source and the build commands, so hopefully that's enough (thanks for providing those!)

DanAlbert commented 4 years ago

r21c is already being finalized, so this will be in r21d at the earliest.

arturbac commented 4 years ago

I think clang usually generates a tarball of the repro case for a crash.

Not in case of linker failure (ld.lld segfault), ld.lld fails at the end of entire build when starts generating assembly from precompiled byte code. The only clue is hopefully source function name. I had to generate preprocessed output of source explicitly by myself taking into account this function name.

arturbac commented 4 years ago

BTW: If You need any other output just let me know and supply clang/ld.lld command to execute.

stephenhines commented 4 years ago

The input file here isn't enough to reproduce the issue unfortunately. If you pass -v to the failing command line, you can get it to dump the exact subcommands that are being run. Then, the ld.lldcommand in there can be run with the --reproduce=repro.tar option to create a repro.tar file that will include all the necessary inputs. You can verify that it reproduces for you by untarring that file and then running ld.lld @response.txt inside of that directory.

arturbac commented 4 years ago

Cant attach it here, after compressing with xz it take 62MB and here is 10MB file limit So I put it into my web server, let me know when I can delete it. http://ebasoft.com.pl/repro.tar.xz

stephenhines commented 4 years ago

Wow, ok. I just pulled it down locally here. I can attach it internally to a bug as needed, so that others can look if necessary. You can remove your copy from your server. Thanks.

arturbac commented 4 years ago

I would be glad if You dont put my entire code here, there are all my archives after compilation.

stephenhines commented 4 years ago

I'm not going to upload it to the public tracker (or even internally if I can avoid it).

NDK r21b reproduces it exactly:

srhines@ringworld:__:repro$ /disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r365631c1/bin/ld.lld @response.txt
Stack dump:
0.      Program arguments: /disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r365631c1/bin/ld.lld @response.txt 
1.      Running pass 'Function Pass Manager' on module 'ld-temp.o'.
2.      Running pass 'ARM Instruction Selection' on function '@_ZN4conv27yCrCb2rgb_aarch64_yps1_chs1E18yuv_data_info_tmplIPKSt4byteEPhj'
#0 0x0000000000e59f92 (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r365631c1/bin/ld.lld+0xe59f92)
#1 0x0000000000e5a727 (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r365631c1/bin/ld.lld+0xe5a727)
#2 0x00007f2a6a344520 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13520)
#3 0x000000000143b92d (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r365631c1/bin/ld.lld+0x143b92d)
#4 0x00007fffce92e6f0 
Segmentation fault

Using our latest toolchain, I see that the bug is still there. We'll track it down.

srhines@ringworld:__:repro$ /disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld @response.txt
'+vfp2d16' is not a recognized feature for this target (ignoring feature)
'+vfp2d16sp' is not a recognized feature for this target (ignoring feature)
'+vfp2d16' is not a recognized feature for this target (ignoring feature)
'+vfp2d16sp' is not a recognized feature for this target (ignoring feature)
Stack dump:
0.      Program arguments: /disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld @response.txt 
1.      Running pass 'Function Pass Manager' on module 'ld-temp.o'.
2.      Running pass 'ARM Instruction Selection' on function '@_ZN4conv27yCrCb2rgb_aarch64_yps1_chs1E18yuv_data_info_tmplIPKSt4byteEPhj'
#0 0x000000000187ed95 (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld+0x187ed95)
#1 0x000000000187f4c0 (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld+0x187f4c0)
#2 0x000000000187f42d (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld+0x187f42d)
#3 0x00007f93a2271520 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13520)
#4 0x00000000015b4ea6 (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld+0x15b4ea6)
Trace/breakpoint trap
stephenhines commented 4 years ago

With a build from TOT LLVM, I see that we are hitting an assertion in the ARM backend. I can try to reduce this down and fix it.

unexpected intrinsic for Neon base update
UNREACHABLE executed at /disk/llvm/llvm-project/llvm/lib/Target/ARM/ARMISelLowering.cpp:13412!
stephenhines commented 4 years ago

Running just llc on the following reduced file triggers the bug. I'll talk to ARM today about it.

broken.ll.txt

arturbac commented 4 years ago

Have You checked ndk r20 ? ld.lld works ok, and of course code works ok on armv7a+neon and armv8a. And i don't get where is problem with vld1x2 or vst3 ? https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics?page=1&search=vld1 uint8x8_t vld1_u8 (uint8_t const ptr) uint8x8x2_t vld1_u8_x2 (uint8_t const ptr) Supported architectures v7/A32/A64

stephenhines commented 4 years ago

https://bugs.llvm.org/show_bug.cgi?id=45824 is the upstream LLVM bug I filed for this. I changed to using the original reduced input file, since Pirama pointed out that I might be causing different problems when stripping away various attributes.

bugpoint-reduced-simplified.ll.txt

arturbac commented 4 years ago

Hope You will have more luck, maybe bug will be more importand, I've reported 5 bugs there all still have status NEW, 4 of them were reported 7 years ago

https://bugs.llvm.org/buglist.cgi?email2=artur%40ebasoft.com.pl&emailreporter2=1&emailtype2=substring&list_id=186405&order=Importance&query_format=advanced&resolution=---

kimishpatel commented 4 years ago

I have just run into this issue today as well. My ndk is r21 as well. Have not tried on 20 though. But I did try with -O0 in which case things work fine.

kimishpatel commented 4 years ago

For my case I see that it is not necessarily due to any specific intrinsic. I think this is strongly tied to optimization pass as mentioned in the bug, since when I remove certain code path I was able to compile it. It was not important what I removed though. So I suspect it just triggers some optimization path that results in seg fault.

emontaemajor commented 4 years ago

Remove devices n computer from my account

rprichard commented 3 years ago

For r22, this bug was fixed in the r399163b clang, in https://android-review.googlesource.com/c/toolchain/llvm_android/+/1440863.

(The NDK bugs #1248 and #1303 might be duplicates: see https://bugs.llvm.org/show_bug.cgi?id=46615#c5.)