Re: [musl] Tracking shared libraries in GDB not working?

[d.dorau@avm.de]

Thanks for your thoughts. I used them to search for further information and found
the missing piece:

https://lists.yoctoproject.org/g/yocto/message/48584

I applied that first patch
https://lists.yoctoproject.org/g/yocto/attachment/48584/0/0007-Teach-dynlink.c-about-DT_MIPS_RLD_MAP_REL.patch

and apparently it seems to solve the issue. :-)

I did a search on this mailing list and couldn't find this patch mentioned here.
Maybe you can include this patch in a future release if you think the solution is correct.

Best regards,
Daniel

-----"Rich Felker" <dalias@libc.org> wrote: -----
>To: d.dorau@avm.de
>From: "Rich Felker" <dalias@libc.org>
>Date: 12/15/2021 04:21PM
>Cc: musl@lists.openwall.com
>Subject: Re: [musl] Tracking shared libraries in GDB not working?
>
>On Wed, Dec 15, 2021 at 02:10:12PM +0100, d.dorau@avm.de 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 192.168.190.33:2345 
>> Remote debugging using 192.168.190.33:2345 
>> 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/ld-musl-mips-sf.so.1...
>
>> Reading symbols from
>/home/ddorau/gu/GU_MASTER/filesystem_temp/lib/.debug/libc.so... 
>> 0x77f40ee0 in _dlstart () from
>/home/ddorau/gu/GU_MASTER/filesystem_temp/lib/ld-musl-mips-sf.so.1 
>> (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/ld-musl-mips-sf.so.1
>> 
>> 
>> 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/ld-linux.so.3
>                                     
>> 0xb6faa168  0xb6fbbc08  Yes
>/home/ddorau/gu/GU_MASTER/filesystem_temp/usr/lib/libbsd.so.0
>                                     
>> 0xb6f956f0  0xb6f95cc8  Yes (*)
>/home/ddorau/gu/GU_MASTER/filesystem_temp/lib/libwdt.so.1
>                                     
>> 0xb6f7d0c8  0xb6f826e0  Yes (*)
>/home/ddorau/gu/GU_MASTER/filesystem_temp/lib/libmxml.so.1
>                                     
>> 0xb6f68984  0xb6f6994c  Yes (*)
>/home/ddorau/gu/GU_MASTER/filesystem_temp/lib/libdl.so.2
>> [...]
>> 
>> 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).
>
>Rich
>