How to debug shared libraries compiled with debug information

Question

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.

Answer 1

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).