[PATCH] D64930: [ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D64930#1642223 <https://reviews.llvm.org/D64930#1642223>, @pcc wrote:

> Hi @MaskRay, it looks like this change has caused some binaries to start segfaulting on Android aarch64 devices. The strange thing is that the segfault happens even before entering the dynamic loader, and furthermore the segfault doesn't happen if I invoke the dynamic loader directly, so I'm guessing that the Linux kernel doesn't like the binary for some reason.
>  F9844553: repro.tar <https://reviews.llvm.org/F9844553>
>  I've attached a repro.tar that I can use to reproduce this problem reliably like so (the "CANNOT LINK EXECUTABLE" error is expected because the runtime library is not present on the device):
>
>   $ ~/l2/ra/bin/ld.lld @response.txt
>   $ adb -s $pixel2 push bin /data/local/tmp
>   bin: 1 file pushed. 3.9 MB/s (15608 bytes in 0.004s)
>   $ adb -s $pixel2 shell
>   walleye:/ # /data/local/tmp/bin
>   Segmentation fault 
>   139|walleye:/ # /system/bin/linker64 /data/local/tmp/bin                                                                                   
>   CANNOT LINK EXECUTABLE "/data/local/tmp/bin": library "libclang_rt.hwasan-aarch64-android.so" not found
>
>
> Without this change:
>
>   $ ~/l/ra/bin/ld.lld @response.txt
>   $ adb -s $pixel2 push bin /data/local/tmp
>   bin: 1 file pushed. 1.2 MB/s (17992 bytes in 0.014s)
>   $ adb -s $pixel2 shell
>   walleye:/ # /data/local/tmp/bin
>   CANNOT LINK EXECUTABLE "/data/local/tmp/bin": library "libclang_rt.hwasan-aarch64-android.so" not found
>
>
> These instructions use Android adb, but given that the problem appears to be with the Linux kernel you might be able to reproduce on regular Linux as well.




In D64930#1642223 <https://reviews.llvm.org/D64930#1642223>, @pcc wrote:

> Hi @MaskRay, it looks like this change has caused some binaries to start segfaulting on Android aarch64 devices. The strange thing is that the segfault happens even before entering the dynamic loader, and furthermore the segfault doesn't happen if I invoke the dynamic loader directly, so I'm guessing that the Linux kernel doesn't like the binary for some reason.
>  F9844553: repro.tar <https://reviews.llvm.org/F9844553>
>  I've attached a repro.tar that I can use to reproduce this problem reliably like so (the "CANNOT LINK EXECUTABLE" error is expected because the runtime library is not present on the device):
>
>   $ ~/l2/ra/bin/ld.lld @response.txt
>   $ adb -s $pixel2 push bin /data/local/tmp
>   bin: 1 file pushed. 3.9 MB/s (15608 bytes in 0.004s)
>   $ adb -s $pixel2 shell
>   walleye:/ # /data/local/tmp/bin
>   Segmentation fault 
>   139|walleye:/ # /system/bin/linker64 /data/local/tmp/bin                                                                                   
>   CANNOT LINK EXECUTABLE "/data/local/tmp/bin": library "libclang_rt.hwasan-aarch64-android.so" not found
>
>
> Without this change:
>
>   $ ~/l/ra/bin/ld.lld @response.txt
>   $ adb -s $pixel2 push bin /data/local/tmp
>   bin: 1 file pushed. 1.2 MB/s (17992 bytes in 0.014s)
>   $ adb -s $pixel2 shell
>   walleye:/ # /data/local/tmp/bin
>   CANNOT LINK EXECUTABLE "/data/local/tmp/bin": library "libclang_rt.hwasan-aarch64-android.so" not found
>
>
> These instructions use Android adb, but given that the problem appears to be with the Linux kernel you might be able to reproduce on regular Linux as well.


I don't have any aarch64 device for testing, but I tried some simple programs on qemu-user and they work:

  aarch64-linux-gnu-gcc -Wl,-rpath,/usr/aarch64-linux-gnu/lib:. -Wl,--dynamic-linker,/usr/aarch64-linux-gnu/lib/ld-2.28.so a.o -o a '-###'
  # copy the linker command line and link with ld.lld
  ./a

@peter.smith tested an earlier revision of D64906 <https://reviews.llvm.org/D64906>+D64930 <https://reviews.llvm.org/D64930> (without the PT_TLS workarounds for various ld.so implementations).

@pcc  Can you test if the program runs with `-z separate-code`? What about `-z max-page-size=65536` (a program should work if runtime pagesz <= max-page-size)? Also `-z norelro`. If strace exists on the system, what does it report?

Delete the `--chroot` line from response.txt and link with aarch64-linux-gnu-ld, try with (a) `-z noseprate-code` (b) `-z separate-code`. Does the program crash as well?

+ at rprichard who's already subscribed..

  ld.lld @response.txtgg
    GNU_RELRO      0x0016b0 0x00000000000036b0 0x00000000000036b0 0x0002e8 0x000950 R   0x1




Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64930/new/

https://reviews.llvm.org/D64930