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

Wed May 4 19:17:01 PDT 2016

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