<div dir="ltr">> <span style="font-size:12.8px"> I just about managed to get something </span><span style="font-size:12.8px">working on a non-Ubuntu distro<br>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. <br><br><br></span><span style="font-size:12.8px">> Since "pc" is different in each case, r0 is inevitably going to point</span><br style="font-size:12.8px"><span style="font-size:12.8px">> to different GOT entries each time __tls_get_addr is called.</span><div><span style="font-size:12.8px">Right. Actually, t</span><span style="font-size:12.8px">he default TLS model of clang/llvm is "global-dynamic" TLS model.</span><span style="font-size:12.8px"> 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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px"> I think I need the </span><span style="font-size:12.8px">preprocessed source and the Clang command that was being used to build </span><span style="font-size:12.8px">it.<br>> </span><span style="font-size:12.8px">To get the command, you can probably just grep the output of "make </span><span style="font-size:12.8px">VERBOSE=1" or whatever.<br></span><span style="font-size:12.8px"><br></span>I will share <span style="font-size:12.8px">the </span><span style="font-size:12.8px">preprocessed source  that you needed with VERBOSE=1 flag shortly. Thanks. </span><br><br><br style="font-size:12.8px"></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 4, 2016 at 10:37 AM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Adding llvm-commits back in, it's best to keep a record of these things)<br>
<span class=""><br>
On 3 May 2016 at 16:31, Geunsik Lim <<a href="mailto:leemgs@gmail.com">leemgs@gmail.com</a>> wrote:<br>
> You can easily reproduce the issue on Ubuntu 14.04 X64 PC as following:<br>
<br>
</span>Thanks for the instructions, I just about managed to get something<br>
working on a non-Ubuntu distro. I think I've spotted what's wrong with<br>
libcoreclr.so: it looks like a bunch of PC-relative constant pools<br>
have been collapsed down to a single one. So in objdump -d we see, for<br>
example:<br>
<br>
  28b428:       f8df 06d4       ldr.w   r0, [pc, #1748] ; 28bb00<br>
  28b42c:       4478            add     r0, pc<br>
  28b42e:       f5a6 e8c6       blx     315bc <__tls_get_addr@plt><br>
  [...]<br>
  28b47a:       f8df 0684       ldr.w   r0, [pc, #1668] ; 28bb00<br>
  28b47e:       4478            add     r0, pc<br>
  28b480:       f5a6 e89c       blx     315bc <__tls_get_addr@plt><br>
<br>
Since "pc" is different in each case, r0 is inevitably going to point<br>
to different GOT entries each time __tls_get_addr is called. An<br>
assembly writer with a penchant for writing unmaintainable code<br>
*might* do that, but a compiler never would (intentionally).<br>
<br>
Unfortunately, I think I'm going to need your help again since that<br>
doesn't happen in the small test cases I write. The key file is<br>
/work/dotnet/arm32/coreclr/src/vm/clsload.cpp. I think I need the<br>
preprocessed source and the Clang command that was being used to build<br>
it.<br>
<br>
To get the command, you can probably just grep the output of "make<br>
VERBOSE=1" or whatever.<br>
<br>
To get the preprocessed-source, the easiest way is probably to run<br>
that command, adding "-save-temps" to the command-line. It should<br>
produce clsload.i, clsload.s and clsload.o all in the working<br>
directory, which are the files I need.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span><div class="HOEnZb"><div class="h5">><br>
> Step1. Download corerun VM including the libcoreclr.so<br>
> =====================================================<br>
> u1404-64bit$leemgs> mkdir -p /work/nfs<br>
> u1404-64bit$leemgs> cd /work/nfs<br>
> u1404-64bit$leemgs> wget<br>
> <a href="https://dncorerepo.blob.core.windows.net/armemulator/runtime-arm-u1404-debug-mode-20160503-global-dynamic-O1.tar.gz" rel="noreferrer" target="_blank">https://dncorerepo.blob.core.windows.net/armemulator/runtime-arm-u1404-debug-mode-20160503-global-dynamic-O1.tar.gz</a><br>
> u1404-64bit$leemgs> wget<br>
> <a href="https://dncorerepo.blob.core.windows.net/armemulator/runtime-arm-u1404-debug-mode-20160503-global-dynamic-O2.tar.gz" rel="noreferrer" target="_blank">https://dncorerepo.blob.core.windows.net/armemulator/runtime-arm-u1404-debug-mode-20160503-global-dynamic-O2.tar.gz</a><br>
> u1404-64bit$leemgs> tar xzf<br>
> runtime-arm-u1404-debug-mode-20160503-global-dynamic-O1.tar.gz<br>
> u1404-64bit$leemgs> tar xzf<br>
> runtime-arm-u1404-debug-mode-20160503-global-dynamic-O2.tar.gz<br>
><br>
><br>
> Step2. Prepare "[Virtual ARM Device] Linux/ARM Emulator"<br>
> ========================================================<br>
> u1404-64bit$leemgs> wget<br>
> <a href="https://dncorerepo.blob.core.windows.net/armemulator/linux-arm-emulator-20160426-1600.3.tar.pbz2" rel="noreferrer" target="_blank">https://dncorerepo.blob.core.windows.net/armemulator/linux-arm-emulator-20160426-1600.3.tar.pbz2</a><br>
> u1404-64bit$leemgs> sudo apt-get install qemu qemu-* libguestfs-*<br>
> u1404-64bit$leemgs> sudo apt-get install pbzip2<br>
> u1404-64bit$leemgs> sudo ln -s /usr/bin/pbzip2 /usr/bin/pbunzip2<br>
> u1404-64bit$leemgs> sudo time tar --use-compress-prog=pbunzip2 -xvf<br>
> ./linux-arm-emulator-2016****.tar.pbz2<br>
> u1404-64bit$leemgs> cd ./linux-arm-emulator-20160426-1600.3<br>
> u1404-64bit$leemgs> vi ./start.sh<br>
> (Remove comment(#) from line 126 and line 129)<br>
> ----start---------------------------<br>
>       . . . . . .<br>
> 126 # sudo mount -o bind /work/nfs     ./platform/my/nfs <=== Remove<br>
> comment(#)<br>
> 127 if ! uname -m | grep -q arm;then QEMU=qemu-arm-static; fi<br>
> 128 sudo chroot ./platform/my/ $QEMU /usr/bin/env PS1="${CHROOT_PS1}"<br>
> /bin/bash<br>
> 129 # sudo umount ./platform/my/nfs  <=== Remove comment(#)<br>
> 130 sudo umount ./platform/my/sys<br>
> 131 sudo umount ./platform/my/proc<br>
>       . . . . . .<br>
> ----end------------------------------<br>
> u1404-64bit$leemgs> ./start.sh (select menu 2)<br>
><br>
><br>
> Step3. Reproduce the issue<br>
> ==========================<br>
> arm@emul#> cd /nfs/runtime-arm-u1404-debug-mode-20160503-global-dynamic-O1/<br>
> <=== O1 flag + libcoreclr.so including __thread variables<br>
> arm@emul#> time ./corerun /dotnet/example/hello.exe<br>
> Hello World<br>
><br>
> real 0m19.809s<br>
> user 0m15.540s<br>
> sys 0m1.480s<br>
><br>
><br>
> arm@emul#> cd /nfs/runtime-arm-u1404-debug-mode-20160503-global-dynamic-O2/<br>
> <=== O2 flag + libcoreclr.so including __thread variables<br>
> arm@emul#> time ./corerun /dotnet/example/hello.exe<br>
> Segmentation fault<br>
><br>
> real 0m3.789s<br>
> user 0m0.230s<br>
> sys 0m0.260s<br>
><br>
><br>
> On Wed, May 4, 2016 at 6:44 AM, Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On 3 May 2016 at 11:30, Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>> wrote:<br>
>> > On 3 May 2016 at 01:14, Geunsik Lim via llvm-dev<br>
>> > <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> >> However, We cannot run (build is okay.) normally hello!!! console<br>
>> >> application with clang/LLVM using -O2 and -O3 optimization level.<br>
>> ><br>
>> > Do you have a copy of this program? My trivial example worked as I<br>
>> > expected, and I couldn't see any obvious flaw in LLVM's output either.<br>
>><br>
>> Ah, I see you meant you had the whole corerun VM trying to execute a<br>
>> trivial example. I'm afraid we're going to need more information to<br>
>> help. Ideally a small C test-case that has the problem, though it<br>
>> might be interesting to compare the libcoreclr.so binaries in the -O1<br>
>> and -O2 cases if you can upload or attach them somewhere.<br>
>><br>
>> Tim.<br>
><br>
><br>
><br>
><br>
> --<br>
> <a href="http://leemgs.fedorapeople.org" rel="noreferrer" target="_blank">http://leemgs.fedorapeople.org</a><br>
> Don't try to avoid pain if you fail.<br>
> If you decided to face the challenges in life,<br>
> you can gain a lot by giving your best.<br>
> Cheolsang Jeong's Book & life<br>
> --<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><a href="http://leemgs.fedorapeople.org" style="font-family:Tahoma" target="_blank">http://leemgs.fedorapeople.org</a><span style="font-family:Tahoma"> </span></div><div>Don't try to avoid pain if you fail.<br>If you decided to face the challenges in life, <br>you can gain a lot by giving your best.<br>Cheolsang Jeong's Book & life<br>--<br></div></div></div>
</div>