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

Thu May 5 02:42:52 PDT 2016

> To get the command, you can probably just grep the output of "make VERBOSE=1"
or whatever.
>
I have collected the more contents to know the reason why clang/llvm make
the bug  at the __thread variable ( via __tls_get_addr) on Linux/ARM when
we enable the aggressive optimization like O2/O3. I have get the log
messages with "VERBOSE=1" flag at build-time as you needed.
* file name: debug-verbose-Ox-log-collec.tar.gz
  download:
https://onedrive.live.com/redir?resid=C93799B86B006829!174&authkey=!AFYEek2M5LIRbgI&ithint=file%2cgz

> adding "-save-temps" to the command-line. It should produce clsload.i,
clsload.s and clsload.o all in the working
>
And, you can also download the assembly files (e.g. clsload.{ i | s | o })
that were generated by "-save-temps" flag.
* file name: debug-O0-to-O3-clsload.c-assembly-with-save-temps.tar.gz
  download:
https://onedrive.live.com/redir?resid=C93799B86B006829!176&authkey=!ACoaXTFQPkbQDoo&ithint=file%2cgz

On Thu, May 5, 2016 at 11:17 AM, Geunsik Lim <leemgs at gmail.com> wrote:

> >  I just about managed to get something working on a non-Ubuntu distro
> Even though you are working on a non-Ubuntu distribution, You can  also
> reproduce the issue with the instruction that I commented. Actually, I have
> been producing the issue on my own CentOS 7 (X64) with some trouble
> shootings as well as Ubuntu 14.04 X64. If you have some troubles on your
> Linux distribution, I can help you by sharing my experience and some tips.
>
>
> > Since "pc" is different in each case, r0 is inevitably going to point
> > to different GOT entries each time __tls_get_addr is called.
> Right. Actually, the default TLS model of clang/llvm is "global-dynamic"
> TLS model. So, it seems that the GOT entry is different each time because
> the program Linker/Loader executes the __tls_get_addr  via GOT/PLT for
> __thread variable.
>
> >  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.
>
> I will share the preprocessed source  that you needed with VERBOSE=1 flag
> shortly. Thanks.
>
>
>
> On Wed, May 4, 2016 at 10:37 AM, Tim Northover <t.p.northover at gmail.com>
> wrote:
>
>> (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
>> > --
>>
>
>
>
> --
> 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
> --
>

-- 
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
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160505/858b214a/attachment.html>