Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Dec 2021 10:20:48 -0500
From: Rich Felker <>
Subject: Re: Tracking shared libraries in GDB not working?

On Wed, Dec 15, 2021 at 02:10:12PM +0100, wrote:
> Hello,
> I have an issue using gdb with musl and am hoping that you might be able to help me:
> I am cross compiling a linux+musl based firmware for a MIPS platform and then
> connecting a multiarch-gdb to a gdbserver on that device.
> This seems to work well, as well as loading all necessary symbols from the host.
> However, when running the application on the target device, gdb seems to be unable
> to track the loading of shared libraries the application was linked against.
> If I break at main() and enter "info shared", only the loader is shown.
> gdb) target remote 
> Remote debugging using 
> Reading symbols from /home/ddorau/gu/GU_MASTER/filesystem_temp/usr/bin/pbd... 
> Reading symbols from /home/ddorau/gu/GU_MASTER/filesystem_temp/usr/bin/..debug/pbd... 
> Reading symbols from /home/ddorau/gu/GU_MASTER/filesystem_temp/lib/ 
> Reading symbols from /home/ddorau/gu/GU_MASTER/filesystem_temp/lib/.debug/ 
> 0x77f40ee0 in _dlstart () from /home/ddorau/gu/GU_MASTER/filesystem_temp/lib/ 
> (gdb) break main 
> Breakpoint 1 at 0x55557e10: file pbserver.c, line 11668. 
> (gdb) continue  Continuing.  
> Breakpoint 1, main (argc=1, argv=0x7fffd564) at pbserver.c:11668
>  11668   { 
> (gdb) info shared 
> >From        To          Syms Read   Shared Object Library 
> 0x77f40740  0x77fba844  Yes         /home/ddorau/gu/GU_MASTER/filesystem_temp/lib/
> If I repeat that whole process on a glibc based ARM platform, it works as expected. There,
> gdb is able to notice all shared libraries the application was linked against and shows them
> correspondingly:
> (gdb) i shared                                                                                                                                 
> >From        To          Syms Read   Shared Object Library                                                                                      
> 0xb6fcea00  0xb6fe9d90  Yes (*)     /home/ddorau/gu/GU_MASTER/filesystem_temp/lib/                                                
> 0xb6faa168  0xb6fbbc08  Yes         /home/ddorau/gu/GU_MASTER/filesystem_temp/usr/lib/                                              
> 0xb6f956f0  0xb6f95cc8  Yes (*)     /home/ddorau/gu/GU_MASTER/filesystem_temp/lib/                                                  
> 0xb6f7d0c8  0xb6f826e0  Yes (*)     /home/ddorau/gu/GU_MASTER/filesystem_temp/lib/                                                 
> 0xb6f68984  0xb6f6994c  Yes (*)     /home/ddorau/gu/GU_MASTER/filesystem_temp/lib/
> [...]
> The libraries are actually loaded successfully, just the gdbserver does not recognize this.
> I'm not familiar with the internals, but assuming gdb would use some kind of breakpoint in the
> loader to notice which libraries are loaded (and to what address).
> It seems I am missing some necessary step for the platform using musl which would enable the same
> behaviour. Am I maybe missing musl related patches for the gdbserver which allows it to track the
> process of loading those shared libraries?
> I would very much appreciate if anyone can help me find the missing piece.

This is almost certainly related to how DT_DEBUG works differently on
MIPS because of historical practice (linker behavior) putting _DYNAMIC
in read-only memory. As a result, MIPS has its own quirky indirect
variant, so this could be a bug in our handling of that, or an
omission of something else needed to go with it, or something wrong
about how gdb was built (not looking for the right info).


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.