[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag

Tue May 3 18:37:03 PDT 2016

(Adding llvm-commits back in, it's best to keep a record of these things)

On 3 May 2016 at 16:31, Geunsik Lim <leemgs at gmail.com> wrote:
> You can easily reproduce the issue on Ubuntu 14.04 X64 PC as following:

Thanks for the instructions, I just about managed to get something
working on a non-Ubuntu distro. I think I've spotted what's wrong with
libcoreclr.so: it looks like a bunch of PC-relative constant pools
have been collapsed down to a single one. So in objdump -d we see, for
example:

  28b428:       f8df 06d4       ldr.w   r0, [pc, #1748] ; 28bb00
  28b42c:       4478            add     r0, pc
  28b42e:       f5a6 e8c6       blx     315bc <__tls_get_addr at plt>
  [...]
  28b47a:       f8df 0684       ldr.w   r0, [pc, #1668] ; 28bb00
  28b47e:       4478            add     r0, pc
  28b480:       f5a6 e89c       blx     315bc <__tls_get_addr at plt>

Since "pc" is different in each case, r0 is inevitably going to point
to different GOT entries each time __tls_get_addr is called. An
assembly writer with a penchant for writing unmaintainable code
*might* do that, but a compiler never would (intentionally).

Unfortunately, I think I'm going to need your help again since that
doesn't happen in the small test cases I write. The key file is
/work/dotnet/arm32/coreclr/src/vm/clsload.cpp. I think I need the
preprocessed source and the Clang command that was being used to build
it.

To get the command, you can probably just grep the output of "make
VERBOSE=1" or whatever.

To get the preprocessed-source, the easiest way is probably to run
that command, adding "-save-temps" to the command-line. It should
produce clsload.i, clsload.s and clsload.o all in the working
directory, which are the files I need.

Cheers.

Tim.
>
> Step1. Download corerun VM including the libcoreclr.so
> =====================================================
> u1404-64bit$leemgs> mkdir -p /work/nfs
> u1404-64bit$leemgs> cd /work/nfs
> u1404-64bit$leemgs> wget
> https://dncorerepo.blob.core.windows.net/armemulator/runtime-arm-u1404-debug-mode-20160503-global-dynamic-O1.tar.gz
> u1404-64bit$leemgs> wget
> https://dncorerepo.blob.core.windows.net/armemulator/runtime-arm-u1404-debug-mode-20160503-global-dynamic-O2.tar.gz
> u1404-64bit$leemgs> tar xzf
> runtime-arm-u1404-debug-mode-20160503-global-dynamic-O1.tar.gz
> u1404-64bit$leemgs> tar xzf
> runtime-arm-u1404-debug-mode-20160503-global-dynamic-O2.tar.gz
>
>
> Step2. Prepare "[Virtual ARM Device] Linux/ARM Emulator"
> ========================================================
> u1404-64bit$leemgs> wget
> https://dncorerepo.blob.core.windows.net/armemulator/linux-arm-emulator-20160426-1600.3.tar.pbz2
> u1404-64bit$leemgs> sudo apt-get install qemu qemu-* libguestfs-*
> u1404-64bit$leemgs> sudo apt-get install pbzip2
> u1404-64bit$leemgs> sudo ln -s /usr/bin/pbzip2 /usr/bin/pbunzip2
> u1404-64bit$leemgs> sudo time tar --use-compress-prog=pbunzip2 -xvf
> ./linux-arm-emulator-2016****.tar.pbz2
> u1404-64bit$leemgs> cd ./linux-arm-emulator-20160426-1600.3
> u1404-64bit$leemgs> vi ./start.sh
> (Remove comment(#) from line 126 and line 129)
> ----start---------------------------
>       . . . . . .
> 126 # sudo mount -o bind /work/nfs     ./platform/my/nfs <=== Remove
> comment(#)
> 127 if ! uname -m | grep -q arm;then QEMU=qemu-arm-static; fi
> 128 sudo chroot ./platform/my/ $QEMU /usr/bin/env PS1="${CHROOT_PS1}"
> /bin/bash
> 129 # sudo umount ./platform/my/nfs  <=== Remove comment(#)
> 130 sudo umount ./platform/my/sys
> 131 sudo umount ./platform/my/proc
>       . . . . . .
> ----end------------------------------
> u1404-64bit$leemgs> ./start.sh (select menu 2)
>
>
> Step3. Reproduce the issue
> ==========================
> arm at emul#> cd /nfs/runtime-arm-u1404-debug-mode-20160503-global-dynamic-O1/
> <=== O1 flag + libcoreclr.so including __thread variables
> arm at emul#> time ./corerun /dotnet/example/hello.exe
> Hello World
>
> real 0m19.809s
> user 0m15.540s
> sys 0m1.480s
>
>
> arm at emul#> cd /nfs/runtime-arm-u1404-debug-mode-20160503-global-dynamic-O2/
> <=== O2 flag + libcoreclr.so including __thread variables
> arm at emul#> time ./corerun /dotnet/example/hello.exe
> Segmentation fault
>
> real 0m3.789s
> user 0m0.230s
> sys 0m0.260s
>
>
> On Wed, May 4, 2016 at 6:44 AM, Tim Northover <t.p.northover at gmail.com>
> wrote:
>>
>> On 3 May 2016 at 11:30, Tim Northover <t.p.northover at gmail.com> wrote:
>> > On 3 May 2016 at 01:14, Geunsik Lim via llvm-dev
>> > <llvm-dev at lists.llvm.org> wrote:
>> >> However, We cannot run (build is okay.) normally hello!!! console
>> >> application with clang/LLVM using -O2 and -O3 optimization level.
>> >
>> > Do you have a copy of this program? My trivial example worked as I
>> > expected, and I couldn't see any obvious flaw in LLVM's output either.
>>
>> Ah, I see you meant you had the whole corerun VM trying to execute a
>> trivial example. I'm afraid we're going to need more information to
>> help. Ideally a small C test-case that has the problem, though it
>> might be interesting to compare the libcoreclr.so binaries in the -O1
>> and -O2 cases if you can upload or attach them somewhere.
>>
>> Tim.
>
>
>
>
> --
> http://leemgs.fedorapeople.org
> Don't try to avoid pain if you fail.
> If you decided to face the challenges in life,
> you can gain a lot by giving your best.
> Cheolsang Jeong's Book & life
> --