|
Message-ID: <20211215152048.GJ7074@brightrain.aerifal.cx> Date: Wed, 15 Dec 2021 10:20:48 -0500 From: Rich Felker <dalias@...c.org> To: d.dorau@....de Cc: musl@...ts.openwall.com Subject: Re: 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.