<div dir="ltr"><span style="font-size:12.8px">> BTW, I am afraid that I can merge the patch to Ubuntu 14.04 and Ubuntu 16.04 LTS repository to support</span><div style=""><span style="font-size:12.8px">> the easy update (e.g. apt-get install llvm-3.6).<br><br>I have posted this issue to Ubuntu's launchpad bug system (e.g. llvm-defaults package) as following: </span></div>* <a href="https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1584089">https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1584089</a><br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 20, 2016 at 11:20 PM, Geunsik Lim <span dir="ltr"><<a href="mailto:leemgs@gmail.com" target="_blank">leemgs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">> <span style="font-size:12.8px">I'd be happy to look at the various clsload.cpp.o files produced</span><br style="font-size:12.8px"><span style="font-size:12.8px">> (there is more than 1 and I can't actually remember which had the</span><br style="font-size:12.8px"></span><span style="font-size:12.8px"><span class="">> problem I'm afraid) and tell you if the TLS accesses are sane.<br><br></span>I have verified that r268662 can resolve the __thread variable issue that I reported to LLVM community.<br>Thank you for your technical support to fix ARM code generation of LLVM back-end.<br><br>BTW, I am afraid that I can merge the patch to Ubuntu 14.04 and Ubuntu 16.04 LTS repository to support</span><div><span style="font-size:12.8px">the easy update (e.g. apt-get install llvm-3.6).</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 20, 2016 at 7:49 AM, Geunsik Lim <span dir="ltr"><<a href="mailto:leemgs@gmail.com" target="_blank">leemgs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p dir="ltr"><span>><span style="font-size:12.8px">So, I am analyzing the build process of CoreCLR to know why we can not see the 'std::cout' message while compiling</span><span style="font-size:12.8px"> <br></span><br></span>I have verified that the modified ARMConstantPoolValue.cpp.o is related to the below files form the our build system. As you can see, there are two libraries (e.g. and ) at the linking procedure; libLLVMARMCodeGen.a(static library) and libLTO.so (shared library). </p><p dir="ltr">* LLVM-3.6 - Building to support Linux/ARM:<br>Building CXX object lib/Target/ARM/CMakeFiles/LLVMARMCodeGen.dir/ARMConstantPoolValue.cpp.o<br><br></p><p dir="ltr">* LLVM-3.6 - Linking files: </p><p dir="ltr">Linking CXX static library ../../libLLVMARMCodeGen.a<br>Linking CXX executable ../../bin/llc<br>Linking CXX executable ../../bin/llvm-ar<br>Linking CXX executable ../../bin/llvm-nm<br>Linking CXX executable ../../bin/llvm-objdump<br>Linking CXX executable ../../bin/opt<br>Linking CXX executable ../../bin/llvm-mc<br>Linking CXX executable ../../bin/llvm-readobj<br>Linking CXX executable ../../bin/llvm-rtdyld<br>Linking CXX executable ../../bin/llvm-c-test<br>Linking CXX shared library ../../lib/libLTO.so<br>Linking CXX executable ../../bin/llvm-lto<br><br></p><p dir="ltr">Actually, I have simply overwritten the all generated files into the existing LLVM folder (.e.g. /usr/lib/llvm-3.6 and /usr/include/llvm-* ) in the build system. However, existing clang has been operating with single shared library (LLVM_BUILD_LLVM_DYLIB:BOOL). It was why I could not see the 'std::cout" message at build time of CoreCLR. So, I have tried to make self-made clang/llvm in my home folder ($HOME/llvm-3.6/) after uninstalling temporarily all clang/llvm packages that are installed in build system. Then, I could see the stdout message normally. I expect that the doing not merging multiple 'ldr' instructions will be executed for using __thread variable in Linux/ARM environment. I will shortly tell you the experimental result of the additional comparisons such as 'Modifier' and 'AddCurrentAddress'.<br></p><span><pre style="font-size:smaller;color:rgb(0,0,0);background-color:rgb(204,204,204)">- ACPV->Modifier == Modifier) {
- if (ACPV->LabelId == LabelId)
- return true;
+ ACPV->Modifier == Modifier &&
+ ACPV->LabelId == LabelId &&
+ ACPV->AddCurrentAddress == AddCurrentAddress) {
</pre>
<p dir="ltr"><br></p></span><p dir="ltr">On the other hands, It seems that Android developers have tried to append emulated-TLS instead of the direct TLS usage to avoid architecture-dependent operation situation. In this case, is problem is just speed? <br>* Clang/driver: emulated TLS mode - <a href="http://reviews.llvm.org/D10524" target="_blank">http://reviews.llvm.org/D10524</a><br><br></p>
<p dir="ltr">BRs, <br>
Geunsik Lim.</p><div><div>
<div style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">> <span style="font-size:12.8px">Maybe the build system is suppressing </span><span style="font-size:12.8px">stdout for some reason?<br>I think that the build system does not suppress stdout at build-time if I append "verbose" option.<br>So, I am analyzing the build process of CoreCLR to know why we can not see the 'std::cout' message while compiling <br>CoreCLR with clang/llvm(including your patch)<br><br><br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 18, 2016 at 12:09 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 17 May 2016 at 19:22, Geunsik Lim <<a href="mailto:leemgs@gmail.com" target="_blank">leemgs@gmail.com</a>> wrote:<br>
> It's strange. I could not see the "[DEBUG] ****" message while compiling<br>
> CoreCLR with Clang/LLVM for Linux/ARM. Is it right? Can you give me an<br>
> opinion?<br>
<br>
</span>That strongly suggests something is wrong. That function ought to be<br>
called hundreds of times while building the source, regardless of the<br>
changed outcome after my patch. Maybe the build system is suppressing<br>
stdout for some reason?<br>
<br>
I'd be happy to look at the various clsload.cpp.o files produced<br>
(there is more than 1 and I can't actually remember which had the<br>
problem I'm afraid) and tell you if the TLS accesses are sane.<br>
<br>
Cheers.<br>
<span><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><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>
</div>
</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><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>
</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>