search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

llvm 'GV doesn't have initializer' assert with using LTO #11268

Open Quuxplusone opened 12 years ago

Quuxplusone commented 12 years ago
Bugzilla Link PR11077
Status NEW
Importance P normal
Reported by Dane Springmeyer (dane@dbsgeo.com)
Reported on 2011-10-05 17:56:21 -0700
Last modified on 2011-10-13 12:11:39 -0700
Version trunk
Hardware Macintosh Linux
CC efriedma@quicinc.com, geek4civic@gmail.com, llvm-bugs@lists.llvm.org, rafael@espindo.la
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also 
Getting this within a build that works great for the remainder of the source
code, but one small so fails when linking. This is on ubuntu 11.04 with
binutils built from cvs head with the gold linker enabled and clang/llvm trunk
from today.

$ clang++ -O4 -use-gold-plugin -save-temps -o plugins/input/ogr.input -shared
plugins/input/ogr/ogr_converter.os plugins/input/ogr/ogr_datasource.os
plugins/input/ogr/ogr_featureset.os plugins/input/ogr/ogr_index_featureset.os -
Lagg -Lsrc -L/usr/local/lib -L/usr/lib -L/home/mapnik/projects/mapnik-static-
build/sources/lib -L/home/mapnik/projects/mapnik-static-build/sources -lgdal -
lmapnik2 -licuuc -lboost_system -lboost_filesystem -lproj -lexpat -ljpeg -ltiff
-lpng -lz -lpthread -lm -lrt -ldl
ld: /home/mapnik/src/llvm/include/llvm/GlobalVariable.h:122: llvm::Constant*
llvm::GlobalVariable::getInitializer(): Assertion `hasInitializer() && "GV
doesn't have initializer!"' failed.
clang: error: unable to execute command: Aborted
clang: error: linker command failed due to signal 2 (use -v to see invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
clang: note: diagnostic msg: Error generating preprocessed source(s).
Quuxplusone commented 12 years ago

It is these files that fail when linking: http://trac.mapnik.org/browser/trunk/plugins/input/ogr and the save-temps fails to output anything (the assertion must be coming first)

Quuxplusone commented 12 years ago

Please attach the .os files which are inputs to the given command; a stack trace would also be nice if you can get it.

Quuxplusone commented 12 years ago 
okay, I've posted the os files to be downloaded from:

http://dbsgeo.com/tmp/ogr_index_featureset.os
http://dbsgeo.com/tmp/ogr_featureset.os
http://dbsgeo.com/tmp/ogr_datasource.os
http://dbsgeo.com/tmp/ogr_converter.os

Any pointers on how to get a stack trace. I tried running the failing clang
command in gdb but the assert does not create a break from which I can grab a
back trace.
Quuxplusone commented 12 years ago 
(In reply to comment #3)
> Any pointers on how to get a stack trace. I tried running the failing clang
> command in gdb but the assert does not create a break from which I can grab a
> back trace.

Run the clang command with -###, then run whatever it prints out and attach gdb
to that.
Quuxplusone commented 12 years ago 
cool, got it, thanks! After working around this error
(http://stackoverflow.com/questions/2702628/gdb-cannot-find-new-threads-generic-
error) I get:

mapnik@mapnik:~/projects/mapnik-static-build/mapnik-trunk$
LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 gdb --args
"/opt/binutils/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m
elf_x86_64 -shared -o plugins/input/ogr.input /usr/lib64/x86_64-linux-
gnu/gcc/x86_64-linux-gnu/4.5.1/../../../../../lib64/crti.o /usr/lib64/x86_64-
linux-gnu/gcc/x86_64-linux-gnu/4.5.1/crtbeginS.o -Lagg -Lsrc -L/usr/local/lib -
L/usr/lib -L/home/mapnik/projects/mapnik-static-build/sources/lib -
L/home/mapnik/projects/mapnik-static-build/sources -L/usr/lib64/x86_64-linux-
gnu/gcc/x86_64-linux-gnu/4.5.1 -L/usr/lib64/x86_64-linux-gnu/gcc/x86_64-linux-
gnu/4.5.1/../../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -
L/usr/lib64/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.1/../../../.. -L/lib -
L/usr/lib -L/usr/lib/x86_64-linux-gnu plugins/input/ogr/ogr_converter.os
plugins/input/ogr/ogr_datasource.os plugins/input/ogr/ogr_featureset.os
plugins/input/ogr/ogr_index_featureset.os -lgdal -lmapnik2 -licuuc -
lboost_system -lboost_filesystem -lproj -lexpat -ljpeg -ltiff -lpng -lz -
lpthread -lm -lrt -ldl -lstdc++ -lm -lgcc_s -lc -lgcc_s /usr/lib64/x86_64-linux-
gnu/gcc/x86_64-linux-gnu/4.5.1/crtendS.o /usr/lib64/x86_64-linux-gnu/gcc/x86_64-
linux-gnu/4.5.1/../../../../../lib64/crtn.o -plugin
/opt/llvm/bin/../lib/LLVMgold.so
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 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 "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/binutils/bin/ld...done.
(gdb) r
Starting program: /opt/binutils/bin/ld -z relro --hash-style=gnu --build-id --
eh-frame-hdr -m elf_x86_64 -shared -o plugins/input/ogr.input /usr/lib64/x86_64-
linux-gnu/gcc/x86_64-linux-gnu/4.5.1/../../../../../lib64/crti.o
/usr/lib64/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.1/crtbeginS.o -Lagg -Lsrc -
L/usr/local/lib -L/usr/lib -L/home/mapnik/projects/mapnik-static-
build/sources/lib -L/home/mapnik/projects/mapnik-static-build/sources -
L/usr/lib64/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.1 -L/usr/lib64/x86_64-
linux-gnu/gcc/x86_64-linux-gnu/4.5.1/../../../../../lib64 -L/lib/../lib64 -
L/usr/lib/../lib64 -L/usr/lib64/x86_64-linux-gnu/gcc/x86_64-linux-
gnu/4.5.1/../../../.. -L/lib -L/usr/lib -L/usr/lib/x86_64-linux-gnu
plugins/input/ogr/ogr_converter.os plugins/input/ogr/ogr_datasource.os
plugins/input/ogr/ogr_featureset.os plugins/input/ogr/ogr_index_featureset.os -
lgdal -lmapnik2 -licuuc -lboost_system -lboost_filesystem -lproj -lexpat -ljpeg
-ltiff -lpng -lz -lpthread -lm -lrt -ldl -lstdc++ -lm -lgcc_s -lc -lgcc_s
/usr/lib64/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.1/crtendS.o
/usr/lib64/x86_64-linux-gnu/gcc/x86_64-linux-
gnu/4.5.1/../../../../../lib64/crtn.o -plugin /opt/llvm/bin/../lib/LLVMgold.so
[Thread debugging using libthread_db enabled]
ld: /home/mapnik/src/llvm/include/llvm/GlobalVariable.h:122: llvm::Constant*
llvm::GlobalVariable::getInitializer(): Assertion `hasInitializer() && "GV
doesn't have initializer!"' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff6ca0d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff6ca0d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6ca4ab6 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff6c997c5 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff5aae913 in (anonymous
namespace)::ModuleLinker::linkGlobalProto(llvm::GlobalVariable*) ()
   from /home/mapnik/src/llvm/Release+Asserts/lib/libLTO.so
#4  0x00007ffff5ab0184 in (anonymous namespace)::ModuleLinker::run() () from
/home/mapnik/src/llvm/Release+Asserts/lib/libLTO.so
#5  0x00007ffff5ab24bc in llvm::Linker::LinkModules(llvm::Module*,
llvm::Module*, std::basic_string<char, std::char_traits<char>,
std::allocator<char> >*)
    () from /home/mapnik/src/llvm/Release+Asserts/lib/libLTO.so
#6  0x00007ffff5a8ae10 in LTOCodeGenerator::addModule(LTOModule*,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) ()
   from /home/mapnik/src/llvm/Release+Asserts/lib/libLTO.so
#7  0x00007ffff7f1b844 in claim_file_hook(ld_plugin_input_file const*, int*) ()
from /opt/llvm/bin/../lib/LLVMgold.so
#8  0x000000000057818c in claim_file (this=0x6de070, input_file=<value
optimized out>, offset=<value optimized out>, filesize=<value optimized out>,
    elf_object=0x0) at plugin.cc:295
#9  gold::Plugin_manager::claim_file (this=0x6de070, input_file=<value
optimized out>, offset=<value optimized out>, filesize=<value optimized out>,
    elf_object=0x0) at plugin.cc:417
#10 0x000000000049eb8d in gold::Archive::get_elf_object_for_member
(this=0xb1d970, off=14644294, punconfigured=0x0) at archive.cc:657
#11 0x000000000049f058 in gold::Archive::include_member (this=0xb1d970,
symtab=0x7fffffffd5f0, layout=0x7fffffffd200, input_objects=0x7fffffffda10,
    off=14644294, mapfile=0x0, sym=0x165e880, why=0x6ce978 "") at archive.cc:946
#12 0x000000000049fa9d in gold::Archive::add_symbols (this=0xb1d970,
symtab=0x7fffffffd5f0, layout=0x7fffffffd200, input_objects=0x7fffffffda10,
    mapfile=0x0) at archive.cc:790
#13 0x000000000049fc49 in gold::Add_archive_symbols::run (this=0x7267a0,
workqueue=0x7fffffffdb40) at archive.cc:1066
#14 0x00000000005d060d in gold::Workqueue::find_and_run_task
(this=0x7fffffffdb40, thread_number=0) at workqueue.cc:319
#15 0x00000000005d098a in gold::Workqueue::process (this=0x7fffffffdb40,
thread_number=0) at workqueue.cc:495
#16 0x0000000000404e01 in main (argc=55, argv=0x7fffffffdd68) at main.cc:248
Quuxplusone commented 12 years ago

Are you able to reproduce the problem with llvm-link and just the IL files?

Quuxplusone commented 12 years ago

not used llvm-link directly before. I will take a look at that and let you know. I will also upgrade to latest llvm/clang to see if that helps. back in a few.

Quuxplusone commented 12 years ago 
not exactly sure the command to use, but I tried this (and it does not produce
a crash or error):

$ /opt/llvm/bin/llvm-link plugins/input/ogr/ogr_converter.os
plugins/input/ogr/ogr_datasource.os -o out.a
mapnik@mapnik:~/projects/mapnik-static-build/_mapnik-trunk$ file out.a
out.a: LLVM bit code

Rafael, is that what you meant?
Quuxplusone commented 12 years ago 
playing around with this more, I noticed the llvm-ld tool.

I tried this:

llvm-ld -o plugins/input/ogr.input /usr/lib64/x86_64-linux-gnu/gcc/x86_64-linux-
gnu/4.5.1/../../../../../lib64/crti.o /usr/lib64/x86_64-linux-gnu/gcc/x86_64-
linux-gnu/4.5.1/crtbeginS.o -Lagg -Lsrc -L/usr/local/lib -L/usr/lib -
L/home/mapnik/projects/mapnik-static-build/sources/lib -L/usr/lib64/x86_64-
linux-gnu/gcc/x86_64-linux-gnu/4.5.1 -L/usr/lib64/x86_64-linux-gnu/gcc/x86_64-
linux-gnu/4.5.1/../../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -
L/usr/lib64/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.1/../../../.. -L/lib -
L/usr/lib -L/usr/lib/x86_64-linux-gnu plugins/input/ogr/ogr_converter.os
plugins/input/ogr/ogr_datasource.os plugins/input/ogr/ogr_featureset.os
plugins/input/ogr/ogr_index_featureset.os -lgdal -lmapnik2 -licuuc -
lboost_system -lboost_filesystem -lstdc++ -lm -lgcc_s -lc -lgcc_s
/usr/lib64/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.1/crtendS.o
/usr/lib64/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.1/../../../../../lib64/crtn.o

And it results in a curious error (but not a crash) that seems to shed light
the same issue:

llvm-ld: error: Cannot link in module '/home/mapnik/projects/mapnik-static-
build/sources/lib/libgdal.a(ogrfeature.o)': Linking globals named
'_ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi':
symbols have different visibilities!
llvm-ld: error: Cannot link archive '/home/mapnik/projects/mapnik-static-
build/sources/lib/libgdal.a'
Quuxplusone commented 12 years ago

the library, libgdal, that is being linked by my program and appears to be causing the problem was compiled with --with-hide-internal-symbols=yes, which must the trigger. That option is described at: http://trac.osgeo.org/gdal/ticket/1810 and http://trac.osgeo.org/gdal/ticket/2673 and

Quuxplusone commented 12 years ago

okay, cool, rebuilding the gdal library to avoid hiding symbols allowed the clang++ compile to work!

clang++ -O4 -use-gold-plugin -o plugins/input/ogr.input -shared plugins/input/ogr/ogr_converter.os plugins/input/ogr/ogr_datasource.os plugins/input/ogr/ogr_featureset.os plugins/input/ogr/ogr_index_featureset.os -Lagg -Lsrc -L/usr/local/lib -L/usr/lib -L/home/mapnik/projects/mapnik-static-build/sources/lib -L/home/mapnik/projects/mapnik-static-build/sources -lgdal -lmapnik2 -licuuc -lboost_system -lboost_filesystem -lproj -lexpat -ljpeg -ltiff -lpng -lz -lpthread -lm -lrt -ldl

So, I guess the issue is that a valid error is being throw properly by llvm-ld but not when the gold linker is used? I'm not sure if llvm-ld is equivalent to the gold linker from binutils - would be great to understand this better.

Either way, feel free to close.

Quuxplusone commented 12 years ago

is gdal being built as bitcode too? If so what is probably happening is that gold is finding the members but the simpler llvm-link is not.

If you can add -t to the ld command line and upload every file the linker uses somewhere, I can try to reproduce the problem.

Quuxplusone commented 12 years ago

Yes, libgdal is built with -O4 (and llvm bitcode). My goal here is to compile every last dependency for my app (mapnik) using clang and LTO, in order to determine if LTO can lead to any measurable runtime perf increasing. All I've seen so far (in light testing) is that LTO helps clang runtimes be about as fast as gcc.

Anyway, here is all of my build steps just in the unlikely case you want to replicate fully: https://gist.github.com/1283049

As far as adding the -t to the ld command line and uploading files involved in the linking, I can try. Libgdal has a lot of dependencies. Do you need all the object files it pulled in, or just the mapnik .os files plus libgdal.a?

Quuxplusone commented 12 years ago

Working on recompiling gdal with internal symbols hidden again... After reconfiguring and running make (without make clean) I hit the same error. This is interesting because I did not originally see it when compiling gdal alone. Now, after a make clean a full make compile does not crash.

So, at least in one case now this was resulting from stale targets (.o files). I'll report back when I am able to recompile mapnik again using this gdal with hidden symbols.