I'm generating symbols file for an executable for minidump. The first line in the minidump symbols file contains specific id of the executable for which the file was generated. How can I find that id inside the executable? When I use readelf to check build id then it's something different (even the length is different).
How can I find that id inside the executable?
Which is that id? Presumably the one your tool uses, except you didn't tell us which tool you actually use.
Most Linux tools (such as GDB) use a special NT_GNU_BUILD_ID note in the elf binary to associate debug info with the binary. You can see that build-id in readelf -n a.out output.
When I use readelf to check build id then it's something different
Again, what exactly do you see? What command do you run?
Maybe they are one and same, and you are just "holding it wrong". Or they are encoded differently, or you are looking at the wrong thing. We can't tell.
Related
I'm trying to link a C++ binary, but I get undefined symbol errors. My binary shouldn't need those symbols, and I'd like to understand the dependency chain causing the linker (GNU ld or GNU gold) think that they are needed. There is libfoo.a containing hundreds of .o files. My program is calling function in libfoo.a. I'd like to get a dependency graph containing all .o files in libfoo.a which the linker thinks are needed to link my program.
I need it because I suspect that there is a mistake somewhere in libfoo.a, calling functions which are not really needed. I can modify the source code of libfoo.a (and thus remove the unneeded calls), and for that I need to understand where the unneeded calls are. The dependency graph could help me find it.
Please note that there is no resulting executable, because of the undefined symbols.
Please note that my ultimate goal is not to build this particular binary, but to make sure that unneeded functions are not called in libfoo.a.
I've looked at man ld, but I couldn't find any command-line flag that could give me more verbose output.
Example error from the linker:
libfoo++.a(foo1.o):foo1.cc:function foo1f: error: undefined reference to 'bar'
How do I figure out what caused foo1.o to be linked to the executable? (It's OK for me that bar is undefined, because I don't need it. My problem is that foo1.o is needed, but it shouldn't be, and I'd like to remove the call which caused foo1.o to be linked in.)
I'd like to get a dependency graph containing all .o files in libfoo.a which the linker thinks are needed to link my program.
The linker map, printed with -M (or --print-map) flag contains exactly that info. If you are using compiler driver (e.g. gcc) to perform the link (you should), then add -Wl,-M to the link line.
I have a need to debug into some calls in system libraries, to understand how the calls differ, and why one or another would be failing.
It is now common for Linux distros to provide stripped system libraries and separate debug symbol files. For example, /lib/libc-2.8.so is stripped of symbols, leaving behind a section named .gnu_debuglink that contains info to find a separate debug file. The separate debug files are installable through a debug package, and contain symbolic info needed by gdb. It's well described here http://www.technovelty.org/code/debug-info-symbols.html and http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
After installing the debug package and the sources, I was expecting that GDB would find the symbols and sources and I would be able to view listings and step into the calls. Instead, gdb tells me "no line number known for xyz"
I've verified that debug-file-location is correct, and directories is set to the source directories.
Is it even possible to do what I want? Am I going about this the wrong way? Is there a simpler way?
Did you try to set the debug-file-directory parameter in GDB? As per the documentation you pointed out, it should do what you want:
set debug-file-directory directories
Set the directories which gdb searches for separate debugging
information files to directory. Multiple directory components can be
set concatenating them by a directory separator.
show debug-file-directory
Show the directories gdb searches for separate debugging
information files.
For instance in my Fedora distribution, the directory is /usr/lib/debug.
You can also define it at compile time with
configure --with-separate-debug-dir=/usr/lib/debug ...
I have a need to debug into some calls in system libraries, to understand how the calls differ, and why one or another would be failing.
It is now common for Linux distros to provide stripped system libraries and separate debug symbol files. For example, /lib/libc-2.8.so is stripped of symbols, leaving behind a section named .gnu_debuglink that contains info to find a separate debug file. The separate debug files are installable through a debug package, and contain symbolic info needed by gdb. It's well described here http://www.technovelty.org/code/debug-info-symbols.html and http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
After installing the debug package and the sources, I was expecting that GDB would find the symbols and sources and I would be able to view listings and step into the calls. Instead, gdb tells me "no line number known for xyz"
I've verified that debug-file-location is correct, and directories is set to the source directories.
Is it even possible to do what I want? Am I going about this the wrong way? Is there a simpler way?
Did you try to set the debug-file-directory parameter in GDB? As per the documentation you pointed out, it should do what you want:
set debug-file-directory directories
Set the directories which gdb searches for separate debugging
information files to directory. Multiple directory components can be
set concatenating them by a directory separator.
show debug-file-directory
Show the directories gdb searches for separate debugging
information files.
For instance in my Fedora distribution, the directory is /usr/lib/debug.
You can also define it at compile time with
configure --with-separate-debug-dir=/usr/lib/debug ...
You can point a single symbol file to gdb with command the:
symbol-file /usr/lib/debug/symbolfile.so
But how to tell gdb to load all symbol-files from given path including subdirectories?
On a Linux system, you should never have to use symbol-file GDB command in the first place.
The trick is to prepare your binaries in such a way that GDB will find the symbol file automatically. This is surprisingly easy to do. Detailed instructions are here.
Use following command:
set solib-search-path path
The solution is to add-symbol-file. For instance, if symbol file is called lib.out:
add-symbol-file lib.out 0
This is particularly useful on embedded system where application developers use a library stored in ROM. The debugger needs the symbol file to reconstruct the stack if execution stops in the middle of a library function call.
This works even if the library was generated on a separate system to which the developers have no access.
Is it possible to run GDB with a program assembled with as and linked with ld? With gcc adding the flag -g allows for debugging but I get the error No symbol table is loaded. Use the "file" command when I try to add breakpoints to a loaded program.
Thanks!
EDIT Maybe I should make it clear that I'm learning and programming in assembly. All I really want is a stack trace but being able to use GDB would be great.
Resolution Running as -g does the trick.
Thank you to all that answered!!
It is possible. However, you need symbols in order to add symbolic breakpoints, and symbols are provided by debugging info; make sure your assembler and linker are providing those. EDIT With GNU as, use as -g. Or just use gcc -g: if you give it a .s file, it will invoke the assembler and linker as appropriate.
GDB understands debugging info in several formats: stabs, COFF, PE, DWARF, SOM. (Some of these are executable formats with debugging sections, others are debug info formats that can be embedded into executables, such as ELF.) gcc -g usually chooses whatever the platform's default is, gcc -ggdb usually chooses the most expressive (depending on your versions, possibly DWARF-3).
If you have debugging info embedded into or linked to by the executable, gdb will try to load it automatically. If you have it elsewhere, you may need to use file to tell gdb where to find it.
You can still debug without symbolic information. For example, you can issue break *0x89abcdef to insert a breakpoint at that address, if there's any code there.
you could try running as with the --gdwarf-2 or -g options, and make sure ld is not called with --strip-debug, and that your makefile/install process is not stripping the executable.
That's not an error preventing debugging, that's an error setting breakpoints in the way you are trying to do it. Since GDB doesn't have any symbol information, you'll have to set the breakpoints some other way.
If you don't have a symbol table, then you can't set breakpoints symbolically (by function name, line of code, etc). You could still set a breakpoint for a specific address, if you know the address you are trying to stop at.
gdb> b 0x12345678
Of course that's only useful if you know that you want to stop at 0x12345678
What does file say about your executable?