[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag
Geunsik Lim via llvm-dev
llvm-dev at lists.llvm.org
Tue May 3 01:14:13 PDT 2016
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>
More information about the llvm-dev
mailing list