I debugged an application using shared library on target linux system. And I came across the following errors:
(gdb) set sysroot /mnt/hgfs/sharefolders/mksdboot-tl/filesystem
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
(gdb)
Does the shared library have any problem or the GDB debugger is wrongly configured?
Any help would be great.
Related
I have the trifecta of gdb complications to untangle. My executable is cross-compiled from x64 to arm, it uses shared objects and the crash is located in one (I know because I added the crash in on purpose), and this is a core dump.
I'm using gdb-multiarch 9.2, but I also have a much older arm-unknown gdb 6.8 available that comes with the toolchain. I can happily get a backtrace if I link static versions of the libs. I pass "-Wl,--build-id" to the linker for all targets and save the unstripped elf/.so to a local .build-id folder in the correct dir structure.
The problems arise when using shared objects. GDB is unable to map the stack addresses to any symbol.
"(gdb) info shared" yields
Cannot access memory at address 0x84c
on the toolchain gdb.
On gdb-multiarch, I get
Cannot access memory at address 0x84c
Cannot access memory at address 0x848
No shared libraries loaded at this time.
I can only assume 0x84c is the non-relocated load address of one of the shared objects.
Here's how I invoke gdb:
# gdb-multiarch -ex "set debug-file-directory ." -ex "set sysroot /usr/local/DigiEL-5.9/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot/" my-exec my-exec-11-1637064196.core
I'm unsure whether I need to pass the sysroot here, but my local ld-linux.so and the remote one are definitely different and might not load .so at the same address.
I tried loading the unstripped .so with "file", which changes nothing.
I would welcome any debugging tips to understand why gdb fails to find the symbols.
I'm trying to debug a segfault in Android's surfaceflinger daemon on a custom made ARM board. The process crashes before dumping the call stack and register content, including the program counter.
Normally I would've used objdump and searched for the program counter. The problem is that part of the call stack is in a shared library. Without using gdb, how can I correlate the program counter with a line in the source file? That is, can the addresses of shared library instructions be determined without running the program?
The simplest solution is to load core dump into gdb and use info symbol <program counter address>, see https://stackoverflow.com/a/7648883/72178.
You can also use addr2line but you will have to provide library starting address in parameters to addr2line, see How to map function address to function in *.so files.
You need your program (and all the relevant shared libraries) to be compiled with debug information (in DWARF format), e.g. by passing some -g (or -g2 or -g3) flag to the GCC compiler when they are built. Notice that with GCC such a debugging option can be mixed with optimization options like -O2
Then you might use utilities like addr2line, or perhaps libraries like libbacktrace. FWIW, the GCC compiler itself (actually its cc1plus) uses that libbacktrace library to print a useful backtrace on SIGSEGV and other terminating signals (on compiler crashes).
BTW, you could (and probably should) enable core(5) dumping and do a post mortem analysis of it with gdb
Notice that due to ASLR, a shared library is loaded (actually mmap(2)-ed) at some "random" page.
Read Drepper's How to Write Shared Libraries paper.
I am trying to debug a program with GDB.
The program runs correctly when run freely. It uses the shared library libc.so.6 which is loaded at address 0x7efff08.
But when i run the program in GDB, the loader loads the shared library libc.so.6 for the program at some other address. My program tries to read the library from the original address (0x07efff08), there it cannot find the ELF header, therefore gives error and terminates. (Invalid ELF header: could not load shared libc.so.6)
Note that I have disabled ASLR.
Is that something to do with shared library relocation? Both GDB and myprogram (being debugged) are using the same shared library.
How can I make sure that the library is loaded at the same address space for my process when run inside GDB?
I am having trouble debugging when using gdbserver. gdb shows error loading one of the shared libraries.
Error while mapping shared library sections:
`target:<path to library>': not in executable format: Invalid argument
I have no problem when attaching with gdb using PID. But gdbserver throws the above error and then I am unable to set any breakpoints in that shared lib.
Any idea what could be wrong? I have other libraries from the same application that don't seem to have any problem.
I am running on
Centos 6.7
gdb version 7.11.1
gcc version 4.4.7
I encountered this error in GDB 7.11 (the one that ships with Android's NDK-r20), and it was caused by my library being relatively large (300MB), which tripped a bug in gdbserver's integer parser that prevented gdbserver from loading any library larger than 268MB. The bug got fixed in GDB 8.2, by raising the limit to 2GB (https://sourceware.org/bugzilla/show_bug.cgi?id=23198).
I used GDB's sysroot feature to work around this issue: https://sourceware.org/gdb/current/onlinedocs/gdb/Files.html#index-set-sysroot
I copied the libraries from the remote target to my local system* and used set sysroot sysroot-here (where "sysroot-here" is a directory containing the directories/files that I had copied). This forces GDB to read symbols locally instead of from the target.
With this sysroot approach, I did not only work around the bug, but I was also able to use the library with full debugging symbols (about 3GB, which would probably also have tripped newer GDB versions).
* I copied all system libraries and the app's libraries, while preserving the full directory structure / file paths. I wanted to only copy the specific library that triggered the bug, but with sysroot it is all or nothing: Either all libraries are to be found locally on the host, or none. See also: A way to have GDB load libraries from local sysroot and remote gdbserver
I found that gdb version 7.10+ has this problem with my particular binary. Still not sure why. This works fine with 7.9 so I downgraded to overcome this issue.
I'm having trouble with gdb and loading debugging information from shared libraries.
The error I get when running from within gdb is:
>>run
Error while mapping shared library sections: libhmmm.so: Success.
....
....
>>break container_main
Error cannot access memory at 0x9f18
The shared library in question exists and is located in the same directory, it contains debugging information and is not stripped.
The application works as expected.
When issuing info sharedlibrary from within gdb all shared libraries are listen but the from and to data is missing for the shared library in question.
Searched but haven't found any solution.
Googling turned up an old bug report and a forum discussion about some similar issue. If you are running GDB version < 6.1 then try upgrading to a newer version.