I have generated an ELF object via MCJIT with debug information, but when I read it back in LLVM it finds an empty debug_ranges section, even though there should be data there. I've dumped the object file to disk, and indeed:
$ readelf -wR objfile
Contents of the .debug_ranges section:
Offset Begin End
00000000 0000000000000089 00000000000000b6
00000000 0000000000000120 0000000000000150
00000000 <End of list>
$ llvm-dwarfdump --debug-dump=ranges objfile
objfile: file format ELF64-x86-64
.debug_ranges contents:
Dumping with plain llvm-dwarfdump objfile gives the slightly more detailed:
.debug_ranges contents:
00000000 <End of list>
00000010 <End of list>
00000020 <End of list>
So it seems that the data is written successfully but not properly read. Any ideas what can cause this and how can I solve it?
I've generated the object file using LLVM 3.2, and tried llvm-dwarfdump from both 3.2 and top-of-trunk.
Related
I have a case where g++ refuses to load a library. I have a file deps/lib/libskgxp11.so. I place -L deps/lib and -lskgxp11 on the g++ command. I get the following error:
error while loading shared libraries: libskgxp11.so: cannot open shared object file: No such file or directory
My overall purpose is to get a test to run with gtest that connects to Oracle, executes select * from dual, and compares the result.
I have the following in Makefile:
g++ -m32 -o $(test_target) -L deps/lib -Wl,--start-group $(dep_libs) -lpthread -ldl -lskgxpr -lskgxp11 -locrb11 -locr11 -lhasgen11 -lnnz11 -lskgxn2 -locrutl11 -lclntsh $(test_objects) -Wl,--end-group
I have used the same basic sequence of -Wl,--start group, all dependent static libraries, all dependent shared libaries, all object files, -Wl,--end-group on other projects and it works just fine.
Notice the -m32, we're doing everything in 32 bits right now. All the other shared libraries load fine, and are all in the same dir:
ls deps/lib/libskgxpr.so deps/lib/libskgxp11.so deps/lib/libocrb11.so deps/lib/libocr11.so deps/lib/libhasgen11.so deps/lib/libnnz11.so deps/lib/libskgxn2.so deps/lib/libocrutl11.so deps/lib/libclntsh.so | cat
deps/lib/libclntsh.so
deps/lib/libhasgen11.so
deps/lib/libnnz11.so
deps/lib/libocr11.so
deps/lib/libocrb11.so
deps/lib/libocrutl11.so
deps/lib/libskgxn2.so
deps/lib/libskgxp11.so
deps/lib/libskgxpr.so
I do notice one strange thing, it seems that the following group of libraries are somehow related:
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
They each seem to define the same functions. The other 4 seem to depend on libskgxp11, in the sense that if I link any of the other 4 by themselves with a -l option, g++ complains that it can't load libskgxp11.
I have a command sequence that can tell me for each remaining function I need to get from some shared lib, which shared lib(s) contain it. It gives the following:
skgxpcdel
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
skgxpcini_with_stats
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
skgxpcon_with_stats
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
...
where skgxpcdel is a func I'm looking for. All of the outstanding functions I need give the same list of the same 5 libraries.
If I run objdump -T on the 5 libraries, they all seem to be 32-bit shared libs, I don't see anything special about the one that doesn't load compared to the ones that do:
for i in deps/lib/libskgxp11.so deps/lib/libskgxpcompat.so deps/lib/libskgxpd.so deps/lib/libskgxpg.so deps/lib/libskgxpr.so; do objdump -T $i | head; done
deps/lib/libskgxp11.so: file format elf32-i386
DYNAMIC SYMBOL TABLE:
0000380c l d .init 00000000 .init
00003b90 l d .text 00000000 .text
00008cc4 l d text.unlikely 00000000 text.unlikely
000a719c l d .fini 00000000 .fini
000a71c0 l d .rodata 00000000 .rodata
000bbe80 l d .eh_frame 00000000 .eh_frame
deps/lib/libskgxpcompat.so: file format elf32-i386
DYNAMIC SYMBOL TABLE:
00000ca0 l d .init 00000000 .init
00000d18 l d .text 00000000 .text
00000e04 l d text.unlikely 00000000 text.unlikely
00001618 l d .fini 00000000 .fini
00001640 l d .rodata 00000000 .rodata
0000188c l d .eh_frame 00000000 .eh_frame
deps/lib/libskgxpd.so: file format elf32-i386
DYNAMIC SYMBOL TABLE:
00000ca0 l d .init 00000000 .init
00000d18 l d .text 00000000 .text
00000e04 l d text.unlikely 00000000 text.unlikely
00001618 l d .fini 00000000 .fini
00001640 l d .rodata 00000000 .rodata
0000188c l d .eh_frame 00000000 .eh_frame
deps/lib/libskgxpg.so: file format elf32-i386
DYNAMIC SYMBOL TABLE:
0000380c l d .init 00000000 .init
00003b90 l d .text 00000000 .text
00008cc4 l d text.unlikely 00000000 text.unlikely
000a719c l d .fini 00000000 .fini
000a71c0 l d .rodata 00000000 .rodata
000bbe80 l d .eh_frame 00000000 .eh_frame
deps/lib/libskgxpr.so: file format elf32-i386
DYNAMIC SYMBOL TABLE:
0000380c l d .init 00000000 .init
00003b90 l d .text 00000000 .text
00008cc4 l d text.unlikely 00000000 text.unlikely
000a719c l d .fini 00000000 .fini
000a71c0 l d .rodata 00000000 .rodata
000bbe80 l d .eh_frame 00000000 .eh_frame
I'm scratching my head wondering why I can't link the libskgxp11.so, and what is the relationship between this group of 5 libs.
Any help would be greatly appreciated.
For reference, here are some command sequences I ran to get the list of problem functions and track down the libs:
# Get what project needs
make run-tests 2>&1 | grep -Po '(?<=undefined reference to ).*' | tr -d "\`'" | sort -u > undefined.txt
# Complete content of undefined.txt
skgxpcdel
skgxpcini_with_stats
skgxpcon_with_stats
skgxpdis
skgxpdmpctx
skgxpdmpobj
skgxp_get_epid
skgxpgettabledef
skgxpmmap
skgxpnetmappush
skgxppost
skgxprqhi
skgxpsz
skgxptrace
skgxpunmap
skgxpveri
skgxpvrpc
skgxpwait
# Get what deps provide, for comparison to what project needs
(for i in deps/lib/*.so;do objdump -TC $i | grep -E '^...............F';done) | grep -v '[*]UND[*]' | awk '{print $NF}' | sort -u > have.txt
# First few lines of have.txt
_A_BSafeError
AddCRLBerToList
add_error_table
afidrv
AHChooseRandomConstructor2
AHSecretCBCConstructor2
AHSecretCBCPadConstructor2
AI_AES_CBC
# See what is common between what project needs and what deps provide
comm -12 have.txt undefined.txt > left.txt
# A diff of undefined.txt and left.txt indicates they are identical
# Get what deps provide, in a way searchable by a person
(for i in deps/lib/*.so;do echo "====$i"; objdump -TC $i | grep -E '^...............F';done) | grep -v '[*]UND[*]' | awk '{print $NF}' > have-files.txt
# Here's a sample of first two shared libs and some of their funcs, from have-files.txt
====deps/lib/libagfw11.so
clsagfw_get_check_type
clsagfw_exit
clsagfw_get_attrvalue
====deps/lib/libagtsh.so
naecsn
lmsapbn
kokogtv
# for each func left, try to find lib that contains it
(for i in `cat left.txt`;do echo $i; for j in deps/lib/*.so;do (objdump -TC $j | grep -E '^...............F' | grep -v '[*]UND[*]' | grep -q $i) && echo " $j"; done; done) 2>&1 | more
# Output for first two missing funcs:
skgxpcdel
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
skgxpcini_with_stats
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
As helpfully suggested in the comments, the problem was occurring trying to run the program. I just needed to use the env command to set LD_LIBRARY_PATH to include the deps/lib dir where all the shared libs are stored:
run-tests: $(test_target)
env "LD_LIBRARY_PATH=deps/lib:$$LD_LIBRARY_PATH" $(test_target)
Thanks.
I am trying to debug into OpenCV code but gdb fails to load the OpenCV source file.
Checking for the source file existence:
$ls -l /home/rui/DriveSo/opencv/modules/core/src/matrix.cpp
-rw-r--r-- 1 rui rui 156046 May 11 21:46 /home/rui/DriveSo/opencv/modules/core/src/matrix.cpp
After linking with OpenCV Debug mode libraries I start dbg and add this to the list of source directories:
$gdb DriveSo
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
....
Reading symbols from DriveSo...done.
(gdb) directory /home/rui/DriveSo/opencv/modules/core/src
Source directories searched: /home/rui/DriveSo/opencv/modules/core/src:$cdir:$cwd
(gdb) break matrix.cpp:2349
No source file named matrix.cpp.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (matrix.cpp:2349) pending.
Even after starting the session gdb still does not find the source file:
(gdb) start
Temporary breakpoint 2 at 0x41d2cf: file ../../DriveSo.dkt/main.cpp, line 11.
Starting program: /home/rui/DriveSo/repositories/trunk/builds/build-DriveSo-Desktop_Qt_5_5_0_GCC_64bit-Debug/DriveSo
....
Temporary breakpoint 2, main (argc=1, argv=0x7fffffffe5a8) at ../../DriveSo.dkt/main.cpp:11
11 QCoreApplication::setApplicationName(QString("DriveSo"));
(gdb)
What can be causing this (to me) unexpected behavior?
Following up on the suggestion by iksajotien, as far as I see the executable has debug information...
$ objdump --syms DriveSo | grep debug
0000000000000000 l d .debug_aranges 0000000000000000 .debug_aranges
0000000000000000 l d .debug_info 0000000000000000 .debug_info
0000000000000000 l d .debug_abbrev 0000000000000000 .debug_abbrev
0000000000000000 l d .debug_line 0000000000000000 .debug_line
0000000000000000 l d .debug_str 0000000000000000 .debug_str
0000000000000000 l d .debug_ranges 0000000000000000 .debug_ranges
...and the shared libraries opened by it...
$ lsof -p 12159
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
...
DriveSo 12159 rui mem REG 8,6 20289800 26740265 /usr/local/lib/libopencv_core.so.3.1.0
...
... also have debug information.
$ objdump --syms /usr/local/lib/libopencv_core.so.3.1.0 | grep debug
0000000000000000 l d .debug_aranges 0000000000000000 .debug_aranges
0000000000000000 l d .debug_info 0000000000000000 .debug_info
0000000000000000 l d .debug_abbrev 0000000000000000 .debug_abbrev
0000000000000000 l d .debug_line 0000000000000000 .debug_line
0000000000000000 l d .debug_str 0000000000000000 .debug_str
0000000000000000 l d .debug_ranges 0000000000000000 .debug_ranges
gdb info shared:
$gdb DriveSo
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
...
Reading symbols from DriveSo...done.
(gdb) run
Starting program: /home/rui/DriveSo/repositories/trunk/builds/build-DriveSo-Desktop_Qt_5_5_0_GCC_64bit-Debug/DriveSo
...
^C
Program received signal SIGINT, Interrupt.
...
(gdb) info shared
From To Syms Read Shared Object Library
0x00007ffff7ddcae0 0x00007ffff7df5130 Yes /lib64/ld-linux-x86-64.so.2
No linux-vdso.so.1
0x00007ffff7158860 0x00007ffff794a910 Yes /usr/local/lib/libopencv_core.so.3.1
0x00007ffff6e5d880 0x00007ffff6e63a0b Yes /usr/local/lib/libopencv_highgui.so.3.1
0x00007ffff5493840 0x00007ffff690ce00 Yes /usr/local/lib/libopencv_imgproc.so.3.1
0x00007ffff50aa6f0 0x00007ffff5158bd1 Yes /usr/local/lib/libopencv_features2d.so.3.1
0x00007ffff4db8640 0x00007ffff4e3de75 Yes /usr/local/lib/libopencv_imgcodecs.so.3.1
0x00007ffff4b72a80 0x00007ffff4b931b0 Yes /usr/local/lib/libopencv_videoio.so.3.1
0x00007ffff47b7d40 0x00007ffff4920f80 Yes /usr/local/lib/libopencv_calib3d.so.3.1
...
---Type <return> to continue, or q <return> to quit---
Looking at gdb source code solib.c has the following at line 1053:
if (! ui_out_is_mi_like_p (interp_ui_out (top_level_interpreter ()))
&& so->symbols_loaded
&& !objfile_has_symbols (so->objfile))
{
so_missing_debug_info = 1;
ui_out_field_string (uiout, "syms-read", "Yes (*)");
}
else
ui_out_field_string (uiout, "syms-read",
so->symbols_loaded ? "Yes" : "No");
I therefore assume symbols are loaded and debug info exists otherwise libraries would be listed with Yes (*) or No
I faced the exact same issue and fixed it by appending an rpath to my makefile.
g++ -o $# $< -L$(LIBS) -lmylib -Wl,-rpath,$(LIBS)
Suppose I've written the following:
enum class Color { Red, Green, Blue, };
template <Color c> Color foo() { return c; }
template Color foo<Color::Green>();
and compiled it. When I look at an objdump of my compiled code, I get:
[einpoklum#myhost /tmp]$ objdump -t f.o | grep "\.text\." | sed 's/^.*\.text\.//;' | c++filt
Color foo<(Color)1>()
Color foo<(Color)1>() 000000000000000b Color foo<(Color)1>()
And if I use abi::__cxa_demangle() for <cxxabi.h> (GCC; maybe it's different with your compiler), it's also similar - (Color)0 or Color)1 are the template parameters, not Red or Green nor Color::Red or Color::Green.
Obviously, I can't have names mangled the way I like them. But - I would really like to be able to obtain (or write?) a variant of the demangling call which instead of "Color foo<(Color)1>()" returns "Color foo<(Color:Green>()" (or "Color foo<(Green>()". Is this doable?
It might be possible for object files with debug info - section .debug_info contains info about enum class Color, it requires some tool to read ELF debug info, parse data semantically and apply/pass info to the c++filt. I don't know if such tools exist or not (maybe, in the GDB it is all glued together)
It is pretty much impossible in general with object files compiled with optimization, or with stripped debug info - information about enum class Color is just NOT there...
From optimized build
objdump -s aaa.o
aaa.o: file format pe-x86-64
Contents of section .text$_Z3fooIL5Color1EES0_v:
0000 554889e5 b8010000 005dc390 90909090 UH.......]......
Contents of section .xdata$_Z3fooIL5Color1EES0_v:
0000 01040205 04030150 .......P
Contents of section .pdata$_Z3fooIL5Color1EES0_v:
0000 00000000 0b000000 00000000 ............
Contents of section .rdata$zzz:
0000 4743433a 20287838 365f3634 2d706f73 GCC: (x86_64-pos
0010 69782d73 65682d72 6576302c 20427569 ix-seh-rev0, Bui
0020 6c742062 79204d69 6e47572d 57363420 lt by MinGW-W64
0030 70726f6a 65637429 20352e33 2e300000 project) 5.3.0..
Debug build has partial contents of section .debug_info:
0070 00000000 00000000 00000002 436f6c6f ............Colo
0080 720004a3 00000001 01a30000 00035265 r.............Re
0090 64000003 47726565 6e000103 426c7565 d...Green...Blue
00a0 00020004 0405696e 74000566 6f6f3c28 ......int..foo<(
00b0 436f6c6f 7229313e 0001065f 5a33666f Color)1>..._Z3fo
00c0 6f494c35 436f6c6f 72314545 53305f76 oIL5Color1EES0_v
00d0 007b0000 00000000 00000000 000b0000 .{..............
00e0 00000000 00019c06 63007b00 00000100 ........c.{.....
00f0 00
I used dumpbin /symbols to see the library I created. Some functions have UNDEF notype in the output. What does that mean? Is there any link to study the structure of dumpbin output?
We can take a look at the MSDN documentation for dumpbin /SYMBOLS:
This option displays the COFF symbol table. Symbol tables exist in all
object files. A COFF symbol table appears in an image file only if it
is linked with /DEBUG.
The following is a description of the output for /SYMBOLS. Additional
information on the meaning of /SYMBOLS output can be found by looking
in winnt.h (IMAGE_SYMBOL and IMAGE_AUX_SYMBOL), or COFF documentation.
Given the following sample dump:
Dump of file main.obj
File Type: COFF OBJECT
COFF SYMBOL TABLE
000 00000000 DEBUG notype Filename | .file
main.cpp
002 000B1FDB ABS notype Static | #comp.id
003 00000000 SECT1 notype Static | .drectve
Section length 26, #relocs 0, #linenums 0, checksum 722C964F
005 00000000 SECT2 notype Static | .text
Section length 23, #relocs 1, #linenums 0, checksum 459FF65F, selection 1 (pick no duplicates)
007 00000000 SECT2 notype () External | _main
008 00000000 UNDEF notype () External | ?MyDump##YAXXZ (void __cdecl MyDump(void))
String Table Size = 0x10 bytes
Summary
26 .drectve
23 .text
The following description, for lines that begin with a symbol number,
describes columns that have information relevant to users:
The first three-digit number is the symbol index/number.
If the third column contains SECTx, the symbol is defined in that
section of the object file. But if UNDEF appears, it is not defined in
that object and must be resolved elsewhere.
The fifth column (Static, External) tells whether the symbol is
visible only within that object, or whether it is public (visible
externally). A Static symbol, _sym, wouldn't be linked to a Public
symbol _sym; these would be two different instances of functions named
_sym.
The last column in a numbered line is the symbol name, both
decorated and undecorated.
And notype() means exactly what it says on the tin: it has no type.
I used dumpbin /symbols to see the library I created. Some functions have UNDEF notype in the output. What does that mean? Is there any link to study the structure of dumpbin output?
We can take a look at the MSDN documentation for dumpbin /SYMBOLS:
This option displays the COFF symbol table. Symbol tables exist in all
object files. A COFF symbol table appears in an image file only if it
is linked with /DEBUG.
The following is a description of the output for /SYMBOLS. Additional
information on the meaning of /SYMBOLS output can be found by looking
in winnt.h (IMAGE_SYMBOL and IMAGE_AUX_SYMBOL), or COFF documentation.
Given the following sample dump:
Dump of file main.obj
File Type: COFF OBJECT
COFF SYMBOL TABLE
000 00000000 DEBUG notype Filename | .file
main.cpp
002 000B1FDB ABS notype Static | #comp.id
003 00000000 SECT1 notype Static | .drectve
Section length 26, #relocs 0, #linenums 0, checksum 722C964F
005 00000000 SECT2 notype Static | .text
Section length 23, #relocs 1, #linenums 0, checksum 459FF65F, selection 1 (pick no duplicates)
007 00000000 SECT2 notype () External | _main
008 00000000 UNDEF notype () External | ?MyDump##YAXXZ (void __cdecl MyDump(void))
String Table Size = 0x10 bytes
Summary
26 .drectve
23 .text
The following description, for lines that begin with a symbol number,
describes columns that have information relevant to users:
The first three-digit number is the symbol index/number.
If the third column contains SECTx, the symbol is defined in that
section of the object file. But if UNDEF appears, it is not defined in
that object and must be resolved elsewhere.
The fifth column (Static, External) tells whether the symbol is
visible only within that object, or whether it is public (visible
externally). A Static symbol, _sym, wouldn't be linked to a Public
symbol _sym; these would be two different instances of functions named
_sym.
The last column in a numbered line is the symbol name, both
decorated and undecorated.
And notype() means exactly what it says on the tin: it has no type.