[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OFE57EEAE8.27A5D6B9-ONC12587B1.0030F359-C12587B1.0030F35E@avm.de>
Date: Mon, 20 Dec 2021 09:54:40 +0100
From: d.dorau@....de
To: musl@...ts.openwall.com
Cc: "Rich Felker" <dalias@...c.org>
Subject: Re: Tracking shared libraries in GDB not working?
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@...c.org> wrote: -----
>To: d.dorau@....de
>From: "Rich Felker" <dalias@...c.org>
>Date: 12/15/2021 04:21PM
>Cc: musl@...ts.openwall.com
>Subject: Re: [musl] Tracking shared libraries in GDB not working?
>
>On Wed, Dec 15, 2021 at 02:10:12PM +0100, d.dorau@....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
>
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.
