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

Fri May 20 07:58:00 PDT 2016

> BTW, I am afraid that I can merge the patch to Ubuntu 14.04 and Ubuntu
16.04  LTS repository to support
> the easy update (e.g. apt-get install llvm-3.6).

I have posted this issue to Ubuntu's launchpad bug system
(e.g. llvm-defaults package) as following:
* https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1584089

On Fri, May 20, 2016 at 11:20 PM, Geunsik Lim <leemgs at gmail.com> wrote:

> > I'd be happy to look at the various clsload.cpp.o files produced
> > (there is more than 1 and I can't actually remember which had the
> > problem I'm afraid) and tell you if the TLS accesses are sane.
>
> I have verified that r268662 can resolve the __thread variable issue that
> I reported to LLVM community.
> Thank you for your technical support to fix ARM code generation of LLVM
> back-end.
>
> BTW, I am afraid that I can merge the patch to Ubuntu 14.04 and Ubuntu
> 16.04  LTS repository to support
> the easy update (e.g. apt-get install llvm-3.6).
>
> On Fri, May 20, 2016 at 7:49 AM, Geunsik Lim <leemgs at gmail.com> wrote:
>
>> >So, I am analyzing the build process of CoreCLR  to know why we can not
>> see the 'std::cout' message while compiling
>>
>> 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).
>>
>> * LLVM-3.6 - Building to support Linux/ARM:
>> Building CXX object
>> lib/Target/ARM/CMakeFiles/LLVMARMCodeGen.dir/ARMConstantPoolValue.cpp.o
>>
>> * LLVM-3.6 - Linking files:
>>
>> Linking CXX static library ../../libLLVMARMCodeGen.a
>> Linking CXX executable ../../bin/llc
>> Linking CXX executable ../../bin/llvm-ar
>> Linking CXX executable ../../bin/llvm-nm
>> Linking CXX executable ../../bin/llvm-objdump
>> Linking CXX executable ../../bin/opt
>> Linking CXX executable ../../bin/llvm-mc
>> Linking CXX executable ../../bin/llvm-readobj
>> Linking CXX executable ../../bin/llvm-rtdyld
>> Linking CXX executable ../../bin/llvm-c-test
>> Linking CXX shared library ../../lib/libLTO.so
>> Linking CXX executable ../../bin/llvm-lto
>>
>> 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'.
>>
>> -      ACPV->Modifier == Modifier) {
>> -    if (ACPV->LabelId == LabelId)
>> -      return true;
>> +      ACPV->Modifier == Modifier &&
>> +      ACPV->LabelId == LabelId &&
>> +      ACPV->AddCurrentAddress == AddCurrentAddress) {
>>
>>
>>
>> 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?
>> * Clang/driver: emulated TLS mode - http://reviews.llvm.org/D10524
>>
>> BRs,
>> Geunsik Lim.
>> > Maybe the build system is suppressing stdout for some reason?
>> I think that the build system does not suppress stdout at build-time if I
>> append "verbose" option.
>> So, I am analyzing the build process of CoreCLR  to know why we can not
>> see the 'std::cout' message while compiling
>> CoreCLR with clang/llvm(including your patch)
>>
>>
>>
>> On Wed, May 18, 2016 at 12:09 PM, Tim Northover <t.p.northover at gmail.com>
>> wrote:
>>
>>> On 17 May 2016 at 19:22, Geunsik Lim <leemgs at gmail.com> wrote:
>>> > It's strange. I could not see the "[DEBUG] ****" message while
>>> compiling
>>> > CoreCLR  with Clang/LLVM for Linux/ARM. Is it right? Can you give me an
>>> > opinion?
>>>
>>> That strongly suggests something is wrong. That function ought to be
>>> called hundreds of times while building the source, regardless of the
>>> changed outcome after my patch. Maybe the build system is suppressing
>>> stdout for some reason?
>>>
>>> I'd be happy to look at the various clsload.cpp.o files produced
>>> (there is more than 1 and I can't actually remember which had the
>>> problem I'm afraid) and tell you if the TLS accesses are sane.
>>>
>>> Cheers.
>>>
>>> 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/20160520/f75615f8/attachment.html>