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

[Geunsik Lim via llvm-commits]

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