Geunsik Lim via llvm-dev
2016-May-03 08:14 UTC
[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag
A few days ago, I tried to change the optimization flag from -O0 to -O2 to
speed up the execution of the application on Ubuntu/ARM 14.04 32 bit.
When I compiled the source code with -O2 flag instead of -O0 flag, I could
not run the application normally by getting always the segmentation fault.
Here is debugging information with GDB command in case of that. As you can
see, we could not execute simple hello!! console application
because of the bug of clang/LLVM when we try to use "static __thread"
variable with -O2 flag.
*root:/dotnet/runtime.release.20160322.2/example> gdb ../corerun
./core.20160322*
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "armv7l-tizen-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to
"word"...
Reading symbols from ../corerun...(no debugging symbols found)...done.
[New LWP 742]
[New LWP 745]
[New LWP 744]
[New LWP 743]
[New LWP 746]
warning: File "/lib/arm-linux-gnueabihf/libthread_db-1.0.so"
auto-loading has been declined
by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /lib/arm-linux-gnueabihf/libthread_db-1.0.so
line to your configuration file "//.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "//.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from
the shell:
info "(gdb)Auto-loading safe path"
warning: Unable to find libthread_db matching inferior's thread
library, thread debugging will not be available.
warning: File "/lib/arm-linux-gnueabihf/libthread_db-1.0.so"
auto-loading has been declined
by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
warning: Unable to find libthread_db matching inferior's thread
library, thread debugging will not be available.
---Type <return> to continue, or q <return> to quit---
Core was generated by `../corerun -c .. ./hello.exe'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x76f7a410 in __tls_get_addr () from /lib/ld-linux-armhf.so.3
(gdb) thread info
No symbol "info" in current context.
(gdb) bt
#0 0x76f7a410 in __tls_get_addr () from /lib/ld-linux-armhf.so.3
#1 0x7699787c in ClassLoader::LoadTypeHandleForTypeKey_Body(TypeKey*,
TypeHandle, ClassLoadLevel) () from
/dotnet/runtime.release.20160222.2/libcoreclr.so
#2 0x76994c4a in ClassLoader::LoadTypeHandleForTypeKey(TypeKey*,
TypeHandle, ClassLoadLevel, InstantiationContext const*) ()
from /dotnet/runtime.release.20160222.2/libcoreclr.so
#3 0x76995a38 in ClassLoader::LoadTypeDefThrowing(Module*, unsigned
int, ClassLoader::NotFoundAction,
ClassLoader::PermitUninstantiatedFlag, unsigned int, ClassLoadLevel,
Instantiation*) ()
from /dotnet/runtime.release.20160222.2/libcoreclr.so
#4 0x769939f2 in ClassLoader::LoadTypeHandleThrowing(NameHandle*,
ClassLoadLevel, Module*) () from
/dotnet/runtime.release.20160222.2/libcoreclr.so
#5 0x769937c2 in ClassLoader::LoadTypeByNameThrowing(Assembly*, char
const*, char const*, ClassLoader::NotFoundAction,
ClassLoader::LoadTypesFlag, ClassLoadLevel) () from
/dotnet/runtime.release.20160222.2/libcoreclr.so
#6 0x76980918 in MscorlibBinder::LookupClass(BinderClassID) ()
from /dotnet/runtime.release.20160222.2/libcoreclr.so
#7 0x769675ca in SystemDomain::LoadBaseSystemClasses() ()
from /dotnet/runtime.release.20160222.2/libcoreclr.so
#8 0x769673ac in SystemDomain::Init() ()
from /dotnet/runtime.release.20160222.2/libcoreclr.so
#9 0x768dbc16 in EEStartupHelper(tagCOINITEE) ()
from /dotnet/runtime.release.20160222.2/libcoreclr.so
---Type <return> to continue, or q <return> to quit---
#10 0x768db070 in EEStartup(tagCOINITEE) ()
from /dotnet/runtime.release.20160222.2/libcoreclr.so
#11 0x768daf56 in EnsureEEStarted(tagCOINITEE) ()
from /dotnet/runtime.release.20160222.2/libcoreclr.so
#12 0x76857998 in CorHost2::Start() ()
from /dotnet/runtime.release.20160222.2/libcoreclr.so
#13 0x76842eac in coreclr_initialize ()
from /dotnet/runtime.release.20160222.2/libcoreclr.so
#14 0x0000a52e in ExecuteManagedAssembly(char const*, char const*,
char const*, int, char const**) ()
#15 0x00009852 in corerun(int, char const**) ()
#16 0x76d38632 in __libc_start_main () from /lib/arm-linux-gnueabihf/libc.so.6
#17 0x00009590 in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
(gdb)
(gdb)
(gdb)
At that time, I defined the "global-dynamic" TLS model by default
with
Clang/LLVM compiler as following:
SET (CMAKE_C_FLAGS_INIT "-Wall -std=c11
-ftls-model=global-dynamic")
We can build and run hello!!! console application with clang/LLVM with -O1
optimization level for Ubuntu/ARM 14.04 32bit as following.
src/pal/tools/clang-compiler-override.txt | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/pal/tools/clang-compiler-override.txt
b/src/pal/tools/clang-compiler-override.txt
index 8bba4a9..ba86d15 100644
--- a/src/pal/tools/clang-compiler-override.txt
+++ b/src/pal/tools/clang-compiler-override.txt
@@ -1,13 +1,22 @@
SET (CMAKE_C_FLAGS_INIT "-Wall -std=c11")
SET (CMAKE_C_FLAGS_DEBUG_INIT "-g -O0")
SET (CLR_C_FLAGS_CHECKED_INIT "-g -O2")
-SET (CMAKE_C_FLAGS_RELEASE_INIT "-g -O3")
+if(CMAKE_SYSTEM_NAME STREQUAL Linux AND CMAKE_SYSTEM_PROCESSOR STREQUAL armv7l)
+ SET (CMAKE_C_FLAGS_RELEASE_INIT "-g0 -O1")
+else()
+ SET (CMAKE_C_FLAGS_RELEASE_INIT "-g0 -O3")
+ message(FATAL_ERROR "RELEASE... c flag no-arm")
+endif()
SET (CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "-g -O2")
SET (CMAKE_CXX_FLAGS_INIT "-Wall -Wno-null-conversion
-std=c++11")
SET (CMAKE_CXX_FLAGS_DEBUG_INIT "-g -O0")
SET (CLR_CXX_FLAGS_CHECKED_INIT "-g -O2")
-SET (CMAKE_CXX_FLAGS_RELEASE_INIT "-g -O3")
+if(CMAKE_SYSTEM_NAME STREQUAL Linux AND CMAKE_SYSTEM_PROCESSOR STREQUAL armv7l)
+ SET (CMAKE_CXX_FLAGS_RELEASE_INIT "-g0 -O1")
+else()
+ SET (CMAKE_CXX_FLAGS_RELEASE_INIT "-g0 -O3")
+endif()
SET (CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT "-g -O2")
In the summary, We can build and run clang/LLVM source code including
__thread variable with -O1 /-O2 flags.
However, We cannot run (build is okay.) normally hello!!! console
application with clang/LLVM using -O2 and -O3 optimization level.
Anyone who has similar experience that gets the __thread variable issue
with -O2/-O3 flags like me?
--
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-dev/attachments/20160503/03634fcf/attachment.html>
Geunsik Lim via llvm-dev
2016-May-03 08:55 UTC
[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag
Now, There are four thread local storage (TLS) models in Clang/LLVM as following: 1) global-dynamic TLS model 2) local-dynamic TLS model 3) local-exec TLS model 4) initial-exec TLS model and emulated-TLS (for Android S/W platform)?? Even though, We can build run normally with the static relocation method by selecting the initial-exec TLS model instead of global-dynamic TLS model (by default) , We need to run the clang application code with global-dynamic (or local-dynamic) TLS model in order that we consider an application code is working with dlopen(3) library call. If someone have already found the appropriate solution for some clang/LLVM applications including 1) __thread variables and 2) -O2/-O3 of the clang language, Could you share us? On Tue, May 3, 2016 at 5:14 PM, Geunsik Lim <leemgs at gmail.com> wrote:> A few days ago, I tried to change the optimization flag from -O0 to -O2 to > speed up the execution of the application on Ubuntu/ARM 14.04 32 bit. > When I compiled the source code with -O2 flag instead of -O0 flag, I > could not run the application normally by getting always the segmentation > fault. > > Here is debugging information with GDB command in case of that. As you can > see, we could not execute simple hello!! console application > because of the bug of clang/LLVM when we try to use "static __thread" > variable with -O2 flag. > > *root:/dotnet/runtime.release.20160322.2/example> gdb ../corerun ./core.20160322* > GNU gdb (GDB) 7.9.1 > Copyright (C) 2015 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "armv7l-tizen-linux-gnueabi". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ../corerun...(no debugging symbols found)...done. > [New LWP 742] > [New LWP 745] > [New LWP 744] > [New LWP 743] > [New LWP 746] > > warning: File "/lib/arm-linux-gnueabihf/libthread_db-1.0.so" auto-loading has been declined > by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > To enable execution of this file add > add-auto-load-safe-path /lib/arm-linux-gnueabihf/libthread_db-1.0.so > line to your configuration file "//.gdbinit". > To completely disable this security protection add > set auto-load safe-path / > line to your configuration file "//.gdbinit". > For more information about this security protection see the > "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: > info "(gdb)Auto-loading safe path" > > warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. > > warning: File "/lib/arm-linux-gnueabihf/libthread_db-1.0.so" auto-loading has been declined > by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > > warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. > ---Type <return> to continue, or q <return> to quit--- > Core was generated by `../corerun -c .. ./hello.exe'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x76f7a410 in __tls_get_addr () from /lib/ld-linux-armhf.so.3 > (gdb) thread info > No symbol "info" in current context. > (gdb) bt > #0 0x76f7a410 in __tls_get_addr () from /lib/ld-linux-armhf.so.3 > #1 0x7699787c in ClassLoader::LoadTypeHandleForTypeKey_Body(TypeKey*, TypeHandle, ClassLoadLevel) () from /dotnet/runtime.release.20160222.2/libcoreclr.so > #2 0x76994c4a in ClassLoader::LoadTypeHandleForTypeKey(TypeKey*, TypeHandle, ClassLoadLevel, InstantiationContext const*) () > from /dotnet/runtime.release.20160222.2/libcoreclr.so > #3 0x76995a38 in ClassLoader::LoadTypeDefThrowing(Module*, unsigned int, ClassLoader::NotFoundAction, ClassLoader::PermitUninstantiatedFlag, unsigned int, ClassLoadLevel, Instantiation*) () > from /dotnet/runtime.release.20160222.2/libcoreclr.so > #4 0x769939f2 in ClassLoader::LoadTypeHandleThrowing(NameHandle*, ClassLoadLevel, Module*) () from /dotnet/runtime.release.20160222.2/libcoreclr.so > #5 0x769937c2 in ClassLoader::LoadTypeByNameThrowing(Assembly*, char const*, char const*, ClassLoader::NotFoundAction, ClassLoader::LoadTypesFlag, ClassLoadLevel) () from /dotnet/runtime.release.20160222.2/libcoreclr.so > #6 0x76980918 in MscorlibBinder::LookupClass(BinderClassID) () > from /dotnet/runtime.release.20160222.2/libcoreclr.so > #7 0x769675ca in SystemDomain::LoadBaseSystemClasses() () > from /dotnet/runtime.release.20160222.2/libcoreclr.so > #8 0x769673ac in SystemDomain::Init() () > from /dotnet/runtime.release.20160222.2/libcoreclr.so > #9 0x768dbc16 in EEStartupHelper(tagCOINITEE) () > from /dotnet/runtime.release.20160222.2/libcoreclr.so > ---Type <return> to continue, or q <return> to quit--- > #10 0x768db070 in EEStartup(tagCOINITEE) () > from /dotnet/runtime.release.20160222.2/libcoreclr.so > #11 0x768daf56 in EnsureEEStarted(tagCOINITEE) () > from /dotnet/runtime.release.20160222.2/libcoreclr.so > #12 0x76857998 in CorHost2::Start() () > from /dotnet/runtime.release.20160222.2/libcoreclr.so > #13 0x76842eac in coreclr_initialize () > from /dotnet/runtime.release.20160222.2/libcoreclr.so > #14 0x0000a52e in ExecuteManagedAssembly(char const*, char const*, char const*, int, char const**) () > #15 0x00009852 in corerun(int, char const**) () > #16 0x76d38632 in __libc_start_main () from /lib/arm-linux-gnueabihf/libc.so.6 > #17 0x00009590 in _start () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > (gdb) > (gdb) > (gdb) > (gdb) > > > > > At that time, I defined the "global-dynamic" TLS model by default with > Clang/LLVM compiler as following: > SET (CMAKE_C_FLAGS_INIT "-Wall -std=c11 > -ftls-model=global-dynamic") > > We can build and run hello!!! console application with clang/LLVM with -O1 > optimization level for Ubuntu/ARM 14.04 32bit as following. > src/pal/tools/clang-compiler-override.txt | 13 +++++++++++-- > > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/src/pal/tools/clang-compiler-override.txt b/src/pal/tools/clang-compiler-override.txt > index 8bba4a9..ba86d15 100644 > --- a/src/pal/tools/clang-compiler-override.txt > +++ b/src/pal/tools/clang-compiler-override.txt > @@ -1,13 +1,22 @@ > SET (CMAKE_C_FLAGS_INIT "-Wall -std=c11") > SET (CMAKE_C_FLAGS_DEBUG_INIT "-g -O0") > SET (CLR_C_FLAGS_CHECKED_INIT "-g -O2") > -SET (CMAKE_C_FLAGS_RELEASE_INIT "-g -O3") > +if(CMAKE_SYSTEM_NAME STREQUAL Linux AND CMAKE_SYSTEM_PROCESSOR STREQUAL armv7l) > + SET (CMAKE_C_FLAGS_RELEASE_INIT "-g0 -O1") > +else() > + SET (CMAKE_C_FLAGS_RELEASE_INIT "-g0 -O3") > + message(FATAL_ERROR "RELEASE... c flag no-arm") > +endif() > SET (CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "-g -O2") > > SET (CMAKE_CXX_FLAGS_INIT "-Wall -Wno-null-conversion -std=c++11") > SET (CMAKE_CXX_FLAGS_DEBUG_INIT "-g -O0") > SET (CLR_CXX_FLAGS_CHECKED_INIT "-g -O2") > -SET (CMAKE_CXX_FLAGS_RELEASE_INIT "-g -O3") > +if(CMAKE_SYSTEM_NAME STREQUAL Linux AND CMAKE_SYSTEM_PROCESSOR STREQUAL armv7l) > + SET (CMAKE_CXX_FLAGS_RELEASE_INIT "-g0 -O1") > +else() > + SET (CMAKE_CXX_FLAGS_RELEASE_INIT "-g0 -O3") > +endif() > SET (CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT "-g -O2") > > > In the summary, We can build and run clang/LLVM source code including > __thread variable with -O1 /-O2 flags. > > However, We cannot run (build is okay.) normally hello!!! console > application with clang/LLVM using -O2 and -O3 optimization level. > > Anyone who has similar experience that gets the __thread variable issue > with -O2/-O3 flags like me? > > > > > > > > -- > 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-dev/attachments/20160503/ec75fb11/attachment-0001.html>
Geunsik Lim via llvm-dev
2016-May-03 10:04 UTC
[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag
In order to share more information, below is the machine instructions of
the "PAL_ThrowExceptionFromContext" function including __thread
variables
from the CoreCLR's seh.cpp source. I wonder why Clan/LLVM can not
guarantee the normal execution of the application code including __thread
variables in case of the aggressive optimization levels (e.g., -O2 and -O3)
========= source: __thread variable in the src/pal/src/exception/seh.cpp
============================== *
https://github.com/dotnet/coreclr/blob/08e1b2f05ba15efff366c4fd70ff475359022bb3/src/pal/src/exception/seh.cpp
171 --*/
172 VOID
173 PALAPI
174 PAL_ThrowExceptionFromContext(CONTEXT* context, PAL_SEHException* ex)
175 {
176 // We need to make a copy of the exception off stack, since the
"ex" is located in one of the stack
177 // frames that will become obsolete by the
ThrowExceptionFromContextInternal and the Th rowExceptionHelper
178 // could overwrite the "ex" object by stack e.g. when
allocating
the low level exceptio n object for "throw".
179 static __thread BYTE
threadLocalExceptionStorage[sizeof(PAL_SEHException)];
180 ThrowExceptionFromContextInternal(context, new
(threadLocalExceptionStorage) PAL_SEHExc eption(*ex));
181 }
======== debug: -O0 <- Build Ok, Running Success
============================================3561791
3561792 0085bc14 <PAL_ThrowExceptionFromContext>:
3561793 85bc14: b580 push {r7, lr}
3561794 85bc16: 466f mov r7, sp
3561795 85bc18: b08a sub sp, #40 ; 0x28
3561796 85bc1a: 460a mov r2, r1
3561797 85bc1c: 4603 mov r3, r0
3561798 85bc1e: 9009 str r0, [sp, #36] ; 0x24
3561799 85bc20: 9108 str r1, [sp, #32]
3561800 85bc22: 2000 movs r0, #0
3561801 85bc24: 4601 mov r1, r0
3561802 85bc26: f8dd c024 ldr.w ip, [sp, #36] ; 0x24
3561803 85bc2a: 2800 cmp r0, #0
3561804 85bc2c: 9207 str r2, [sp, #28]
3561805 85bc2e: 9306 str r3, [sp, #24]
3561806 85bc30: f8cd c014 str.w ip, [sp, #20]
3561807 85bc34: 9104 str r1, [sp, #16]
3561808 85bc36: d10d bne.n 85bc54
<PAL_ThrowExceptionFromContext+0x40>
3561809 85bc38: e7ff b.n 85bc3a
<PAL_ThrowExceptionFromContext+0x26>
3561810 85bc3a: 9908 ldr r1, [sp, #32]
3561811 85bc3c: 480a ldr r0, [pc, #40] ; (85bc68
<PAL_ThrowExceptionFromContext+0x54>)
3561812 85bc3e: 4478 add r0, pc
3561813 85bc40: 9103 str r1, [sp, #12]
3561814 85bc42: f7db cf96 blx 37b70 <_init+0xb34>
3561815 85bc46: 9002 str r0, [sp, #8]
3561816 85bc48: 9903 ldr r1, [sp, #12]
3561817 85bc4a: f66d f1ef bl 2c902c
<_ZN16PAL_SEHExceptionC2ERKS_>
3561818 85bc4e: 9802 ldr r0, [sp, #8]
3561819 85bc50: 9004 str r0, [sp, #16]
3561820 85bc52: e7ff b.n 85bc54
<PAL_ThrowExceptionFromContext+0x40>
3561821 85bc54: 9804 ldr r0, [sp, #16]
3561822 85bc56: 9905 ldr r1, [sp, #20]
3561823 85bc58: 9001 str r0, [sp, #4]
3561824 85bc5a: 4608 mov r0, r1
3561825 85bc5c: 9901 ldr r1, [sp, #4]
3561826 85bc5e: f0aa fa47 bl 9060f0
<ThrowExceptionFromContextInternal>
3561827 85bc62: b00a add sp, #40 ; 0x28
3561828 85bc64: bd80 pop {r7, pc}
3561829 85bc66: bf00 nop
3561830 85bc68: 00293806 .word 0x00293806
3561831
========== debug: -O1 <- Build Ok, Running Success
===================================
1955139
1955140 005103f0 <PAL_ThrowExceptionFromContext>:
1955141 5103f0: e92d 48f0 stmdb sp!, {r4, r5, r6, r7, fp,
lr}
1955142 5103f4: af03 add r7, sp, #12
1955143 5103f6: 4605 mov r5, r0
1955144 5103f8: 4807 ldr r0, [pc, #28] ; (510418
<PAL_ThrowExceptionFromContext+0x28>)
1955145 5103fa: 460c mov r4, r1
1955146 5103fc: 4478 add r0, pc
1955147 5103fe: f727 e06e blx 374dc <_init+0xba0>
1955148 510402: 4606 mov r6, r0
1955149 510404: 4621 mov r1, r4
1955150 510406: f49f f8cf bl 1af5a8
<_ZN16PAL_SEHExceptionC2ERKS_>
1955151 51040a: 4628 mov r0, r5
1955152 51040c: 4631 mov r1, r6
1955153 51040e: e8bd 48f0 ldmia.w sp!, {r4, r5, r6, r7, fp,
lr}
1955154 510412: f073 bb87 b.w 583b24
<ThrowExceptionFromContextInternal>
1955155 510416: bf00 nop
1955156 510418: 00270038 .word 0x00270038
1955157
========== debug: -O2 <- Build Ok, Running Failed
=====================================
2557238
2557239 006ba338 <PAL_ThrowExceptionFromContext>:
2557240 6ba338: e92d 41f0 stmdb sp!, {r4, r5, r6, r7, r8,
lr}
2557241 6ba33c: af03 add r7, sp, #12
2557242 6ba33e: 4680 mov r8, r0
2557243 6ba340: 4812 ldr r0, [pc, #72] ; (6ba38c
<PAL_ThrowExceptionFromContext+0x54>)
2557244 6ba342: 460c mov r4, r1
2557245 6ba344: 4478 add r0, pc
2557246 6ba346: f577 e13a blx 315bc <_init+0xca4>
2557247 6ba34a: 4606 mov r6, r0
2557248 6ba34c: f04f 31ff mov.w r1, #4294967295 ; 0xffffffff
2557249 6ba350: 6031 str r1, [r6, #0]
2557250 6ba352: f106 000c add.w r0, r6, #12
2557251 6ba356: f104 010c add.w r1, r4, #12
2557252 6ba35a: 2250 movs r2, #80 ; 0x50
2557253 6ba35c: f106 0560 add.w r5, r6, #96 ; 0x60
2557254 6ba360: 6070 str r0, [r6, #4]
2557255 6ba362: 60b5 str r5, [r6, #8]
2557256 6ba364: f576 e7ea blx 3133c <_init+0xa24>
2557257 6ba368: f104 0160 add.w r1, r4, #96 ; 0x60
2557258 6ba36c: 4628 mov r0, r5
2557259 6ba36e: f44f 72d0 mov.w r2, #416 ; 0x1a0
2557260 6ba372: f576 e7e4 blx 3133c <_init+0xa24>
2557261 6ba376: f8d4 0200 ldr.w r0, [r4, #512] ; 0x200
2557262 6ba37a: 4631 mov r1, r6
2557263 6ba37c: f8c6 0200 str.w r0, [r6, #512] ; 0x200
2557264 6ba380: 4640 mov r0, r8
2557265 6ba382: e8bd 41f0 ldmia.w sp!, {r4, r5, r6, r7, r8,
lr}
2557266 6ba386: f080 bd45 b.w 73ae14
<ThrowExceptionFromContextInternal>
2557267 6ba38a: bf00 nop
2557268 6ba38c: 002820e4 .word 0x002820e4
2557269
========== debug: -O3 <- Build Ok, Running Failed
====================================
2642852 006f3d54 <PAL_ThrowExceptionFromContext>:
2642853 6f3d54: e92d 41f0 stmdb sp!, {r4, r5, r6, r7, r8,
lr}
2642854 6f3d58: af03 add r7, sp, #12
2642855 6f3d5a: 4680 mov r8, r0
2642856 6f3d5c: 4812 ldr r0, [pc, #72] ; (6f3da8
<PAL_ThrowExceptionFromContext+0x54>)
2642857 6f3d5e: 460c mov r4, r1
2642858 6f3d60: 4478 add r0, pc
2642859 6f3d62: f53d e410 blx 31584 <_init+0xca4>
2642860 6f3d66: 4606 mov r6, r0
2642861 6f3d68: f04f 31ff mov.w r1, #4294967295 ; 0xffffffff
2642862 6f3d6c: 6031 str r1, [r6, #0]
2642863 6f3d6e: f106 000c add.w r0, r6, #12
2642864 6f3d72: f104 010c add.w r1, r4, #12
2642865 6f3d76: 2250 movs r2, #80 ; 0x50
2642866 6f3d78: f106 0560 add.w r5, r6, #96 ; 0x60
2642867 6f3d7c: 6070 str r0, [r6, #4]
2642868 6f3d7e: 60b5 str r5, [r6, #8]
2642869 6f3d80: f53d e2c0 blx 31304 <_init+0xa24>
2642870 6f3d84: f104 0160 add.w r1, r4, #96 ; 0x60
2642871 6f3d88: 4628 mov r0, r5
2642872 6f3d8a: f44f 72d0 mov.w r2, #416 ; 0x1a0
2642873 6f3d8e: f53d e2ba blx 31304 <_init+0xa24>
2642874 6f3d92: f8d4 0200 ldr.w r0, [r4, #512] ; 0x200
2642875 6f3d96: 4631 mov r1, r6
2642876 6f3d98: f8c6 0200 str.w r0, [r6, #512] ; 0x200
2642877 6f3d9c: 4640 mov r0, r8
2642878 6f3d9e: e8bd 41f0 ldmia.w sp!, {r4, r5, r6, r7, r8,
lr}
2642879 6f3da2: f081 bee1 b.w 775b68
<ThrowExceptionFromContextInternal>
2642880 6f3da6: bf00 nop
2642881 6f3da8: 002906c8 .word 0x002906c8
End of line.
On Tue, May 3, 2016 at 5:55 PM, Geunsik Lim <leemgs at gmail.com> wrote:
> Now, There are four thread local storage (TLS) models in Clang/LLVM as
> following:
> 1) global-dynamic TLS model
> 2) local-dynamic TLS model
> 3) local-exec TLS model
> 4) initial-exec TLS model
> and emulated-TLS (for Android S/W platform)??
>
> Even though, We can build run normally with the static relocation method
> by selecting the initial-exec TLS model instead of global-dynamic TLS
> model (by default) , We need to run the clang application code with
> global-dynamic (or local-dynamic) TLS model in order that we consider an
> application code is working with dlopen(3) library call.
>
> If someone have already found the appropriate solution for some clang/LLVM
> applications including 1) __thread variables and 2) -O2/-O3 of the clang
> language, Could you share us?
>
>
>
>
> On Tue, May 3, 2016 at 5:14 PM, Geunsik Lim <leemgs at gmail.com>
wrote:
>
>> A few days ago, I tried to change the optimization flag from -O0 to -O2
>> to speed up the execution of the application on Ubuntu/ARM 14.04 32
bit.
>> When I compiled the source code with -O2 flag instead of -O0 flag, I
>> could not run the application normally by getting always the
segmentation
>> fault.
>>
>> Here is debugging information with GDB command in case of that. As you
>> can see, we could not execute simple hello!! console application
>> because of the bug of clang/LLVM when we try to use "static
__thread"
>> variable with -O2 flag.
>>
>> *root:/dotnet/runtime.release.20160322.2/example> gdb ../corerun
./core.20160322*
>> GNU gdb (GDB) 7.9.1
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
>> and "show warranty" for details.
>> This GDB was configured as "armv7l-tizen-linux-gnueabi".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>.
>> Find the GDB manual and other documentation resources online at:
>> <http://www.gnu.org/software/gdb/documentation/>.
>> For help, type "help".
>> Type "apropos word" to search for commands related to
"word"...
>> Reading symbols from ../corerun...(no debugging symbols found)...done.
>> [New LWP 742]
>> [New LWP 745]
>> [New LWP 744]
>> [New LWP 743]
>> [New LWP 746]
>>
>> warning: File "/lib/arm-linux-gnueabihf/libthread_db-1.0.so"
auto-loading has been declined
>> by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
>> To enable execution of this file add
>> add-auto-load-safe-path
/lib/arm-linux-gnueabihf/libthread_db-1.0.so
>> line to your configuration file "//.gdbinit".
>> To completely disable this security protection add
>> set auto-load safe-path /
>> line to your configuration file "//.gdbinit".
>> For more information about this security protection see the
>> "Auto-loading safe path" section in the GDB manual. E.g.,
run from the shell:
>> info "(gdb)Auto-loading safe path"
>>
>> warning: Unable to find libthread_db matching inferior's thread
library, thread debugging will not be available.
>>
>> warning: File "/lib/arm-linux-gnueabihf/libthread_db-1.0.so"
auto-loading has been declined
>> by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
>>
>> warning: Unable to find libthread_db matching inferior's thread
library, thread debugging will not be available.
>> ---Type <return> to continue, or q <return> to quit---
>> Core was generated by `../corerun -c .. ./hello.exe'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0 0x76f7a410 in __tls_get_addr () from /lib/ld-linux-armhf.so.3
>> (gdb) thread info
>> No symbol "info" in current context.
>> (gdb) bt
>> #0 0x76f7a410 in __tls_get_addr () from /lib/ld-linux-armhf.so.3
>> #1 0x7699787c in ClassLoader::LoadTypeHandleForTypeKey_Body(TypeKey*,
TypeHandle, ClassLoadLevel) () from
/dotnet/runtime.release.20160222.2/libcoreclr.so
>> #2 0x76994c4a in ClassLoader::LoadTypeHandleForTypeKey(TypeKey*,
TypeHandle, ClassLoadLevel, InstantiationContext const*) ()
>> from /dotnet/runtime.release.20160222.2/libcoreclr.so
>> #3 0x76995a38 in ClassLoader::LoadTypeDefThrowing(Module*, unsigned
int, ClassLoader::NotFoundAction, ClassLoader::PermitUninstantiatedFlag,
unsigned int, ClassLoadLevel, Instantiation*) ()
>> from /dotnet/runtime.release.20160222.2/libcoreclr.so
>> #4 0x769939f2 in ClassLoader::LoadTypeHandleThrowing(NameHandle*,
ClassLoadLevel, Module*) () from
/dotnet/runtime.release.20160222.2/libcoreclr.so
>> #5 0x769937c2 in ClassLoader::LoadTypeByNameThrowing(Assembly*, char
const*, char const*, ClassLoader::NotFoundAction, ClassLoader::LoadTypesFlag,
ClassLoadLevel) () from /dotnet/runtime.release.20160222.2/libcoreclr.so
>> #6 0x76980918 in MscorlibBinder::LookupClass(BinderClassID) ()
>> from /dotnet/runtime.release.20160222.2/libcoreclr.so
>> #7 0x769675ca in SystemDomain::LoadBaseSystemClasses() ()
>> from /dotnet/runtime.release.20160222.2/libcoreclr.so
>> #8 0x769673ac in SystemDomain::Init() ()
>> from /dotnet/runtime.release.20160222.2/libcoreclr.so
>> #9 0x768dbc16 in EEStartupHelper(tagCOINITEE) ()
>> from /dotnet/runtime.release.20160222.2/libcoreclr.so
>> ---Type <return> to continue, or q <return> to quit---
>> #10 0x768db070 in EEStartup(tagCOINITEE) ()
>> from /dotnet/runtime.release.20160222.2/libcoreclr.so
>> #11 0x768daf56 in EnsureEEStarted(tagCOINITEE) ()
>> from /dotnet/runtime.release.20160222.2/libcoreclr.so
>> #12 0x76857998 in CorHost2::Start() ()
>> from /dotnet/runtime.release.20160222.2/libcoreclr.so
>> #13 0x76842eac in coreclr_initialize ()
>> from /dotnet/runtime.release.20160222.2/libcoreclr.so
>> #14 0x0000a52e in ExecuteManagedAssembly(char const*, char const*, char
const*, int, char const**) ()
>> #15 0x00009852 in corerun(int, char const**) ()
>> #16 0x76d38632 in __libc_start_main () from
/lib/arm-linux-gnueabihf/libc.so.6
>> #17 0x00009590 in _start ()
>> Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
>> (gdb)
>> (gdb)
>> (gdb)
>> (gdb)
>>
>>
>>
>>
>> At that time, I defined the "global-dynamic" TLS model by
default with
>> Clang/LLVM compiler as following:
>> SET (CMAKE_C_FLAGS_INIT "-Wall -std=c11
>> -ftls-model=global-dynamic")
>>
>> We can build and run hello!!! console application with clang/LLVM with
>> -O1 optimization level for Ubuntu/ARM 14.04 32bit as following.
>> src/pal/tools/clang-compiler-override.txt | 13 +++++++++++--
>>
>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/pal/tools/clang-compiler-override.txt
b/src/pal/tools/clang-compiler-override.txt
>> index 8bba4a9..ba86d15 100644
>> --- a/src/pal/tools/clang-compiler-override.txt
>> +++ b/src/pal/tools/clang-compiler-override.txt
>> @@ -1,13 +1,22 @@
>> SET (CMAKE_C_FLAGS_INIT "-Wall -std=c11")
>> SET (CMAKE_C_FLAGS_DEBUG_INIT "-g -O0")
>> SET (CLR_C_FLAGS_CHECKED_INIT "-g -O2")
>> -SET (CMAKE_C_FLAGS_RELEASE_INIT "-g -O3")
>> +if(CMAKE_SYSTEM_NAME STREQUAL Linux AND CMAKE_SYSTEM_PROCESSOR
STREQUAL armv7l)
>> + SET (CMAKE_C_FLAGS_RELEASE_INIT "-g0 -O1")
>> +else()
>> + SET (CMAKE_C_FLAGS_RELEASE_INIT "-g0 -O3")
>> + message(FATAL_ERROR "RELEASE... c flag no-arm")
>> +endif()
>> SET (CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "-g -O2")
>>
>> SET (CMAKE_CXX_FLAGS_INIT "-Wall
-Wno-null-conversion -std=c++11")
>> SET (CMAKE_CXX_FLAGS_DEBUG_INIT "-g -O0")
>> SET (CLR_CXX_FLAGS_CHECKED_INIT "-g -O2")
>> -SET (CMAKE_CXX_FLAGS_RELEASE_INIT "-g -O3")
>> +if(CMAKE_SYSTEM_NAME STREQUAL Linux AND CMAKE_SYSTEM_PROCESSOR
STREQUAL armv7l)
>> + SET (CMAKE_CXX_FLAGS_RELEASE_INIT "-g0 -O1")
>> +else()
>> + SET (CMAKE_CXX_FLAGS_RELEASE_INIT "-g0 -O3")
>> +endif()
>> SET (CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT "-g -O2")
>>
>>
>> In the summary, We can build and run clang/LLVM source code including
>> __thread variable with -O1 /-O2 flags.
>>
>> However, We cannot run (build is okay.) normally hello!!! console
>> application with clang/LLVM using -O2 and -O3 optimization level.
>>
>> Anyone who has similar experience that gets the __thread variable issue
>> with -O2/-O3 flags like me?
>>
>>
>>
>>
>>
>>
>>
>> --
>> 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-dev/attachments/20160503/a2477966/attachment.html>
Tim Northover via llvm-dev
2016-May-03 18:30 UTC
[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag
Hi Geusnik, On 3 May 2016 at 01:14, Geunsik Lim via llvm-dev <llvm-dev at lists.llvm.org> wrote:> However, We cannot run (build is okay.) normally hello!!! console > application with clang/LLVM using -O2 and -O3 optimization level.Do you have a copy of this program? My trivial example worked as I expected, and I couldn't see any obvious flaw in LLVM's output either. Cheers. Tim.
Tim Northover via llvm-dev
2016-May-03 21:44 UTC
[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag
On 3 May 2016 at 11:30, Tim Northover <t.p.northover at gmail.com> wrote:> On 3 May 2016 at 01:14, Geunsik Lim via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> However, We cannot run (build is okay.) normally hello!!! console >> application with clang/LLVM using -O2 and -O3 optimization level. > > Do you have a copy of this program? My trivial example worked as I > expected, and I couldn't see any obvious flaw in LLVM's output either.Ah, I see you meant you had the whole corerun VM trying to execute a trivial example. I'm afraid we're going to need more information to help. Ideally a small C test-case that has the problem, though it might be interesting to compare the libcoreclr.so binaries in the -O1 and -O2 cases if you can upload or attach them somewhere. Tim.