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

[Geunsik Lim via llvm-commits]

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