I'm compiling a program with debug simbols that links to a shared library (liballegro) also compiled with debug symbols. When I try to step into a function of this shared library I can't see any code.
file myBin
mybin: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d4133ef127e81ffb007c4c17e10f4ddaefac6a0f, with debug_info, not stripped
file lib/liballegro-debug.so
liballegro-debug.so.5.2.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=dd75ca87e0ed86832ed02a1c40548a055ad4f551, with debug_info, not stripped
GDB shows how this lib is loaded with debug information:
(gdb) info shared
From To Syms Read Shared Object Library
0x00007ffff7dd9b40 0x00007ffff7df5110 Yes (*) /lib64/ld-linux-x86-64.so.2
0x00007ffff7a5a0d0 0x00007ffff7b84591 Yes correct/path/to/liballegro-debug.so
0x00007ffff76ffd60 0x00007ffff7778eef Yes (*) /usr/lib/libm.so.6
0x00007ffff74e1640 0x00007ffff74eefb1 Yes (*) /usr/lib/libpthread.so.0
[...]
So I put a breakpoint in a function call who lives in the shared library (al_load_bitmap):
90 level->tileset.parent = al_load_bitmap(filename);
The source code of al_load_bitmap is in the file path/to/src/bitmap_io.c which is listed in the output of gdb info sources
And step into it:
(gdb) si
0x0000555555555f00 in al_load_bitmap@plt ()
At this point I can't figure how to see the source code of this function, as list comand show nothing.
How can I debug what happens inside this function?
PD: I tried also with lldb and is the same result, so I'm missing something.
Thank you.
al_load_bitmap@plt is the PLT stub (located in the main program, not the shared object), which does not have debugging information. You need to step over several instructions, then you'll reach the actual function, which hopefully has debugging information. You may also encounter the dynamic linker if lazy binding is active (it can be disabled with the LD_BIND_NOW=1 environment variable setting).
For these reasons, it is much easier to use the s (step) command to enter the function (if the called function has debugging information).
There are some cases when file reports the presence of debugging information, but you still don't get useful behavior from GDB (such as line numbers or local variable access). That's because there are several types of debugging information, and some distributions/developers perform partial stripping or debuginfo separation, leaving only the bare minimum to generate backtraces in the ELF file (which is what file reports as not stripped).