From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14035 invoked from network); 15 Dec 2021 15:21:03 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Dec 2021 15:21:03 -0000 Received: (qmail 5129 invoked by uid 550); 15 Dec 2021 15:21:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 4073 invoked from network); 15 Dec 2021 15:21:00 -0000 Date: Wed, 15 Dec 2021 10:20:48 -0500 From: Rich Felker To: d.dorau@avm.de Cc: musl@lists.openwall.com Message-ID: <20211215152048.GJ7074@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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