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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 30742 invoked from network); 15 Dec 2021 13:10:27 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Dec 2021 13:10:27 -0000 Received: (qmail 27709 invoked by uid 550); 15 Dec 2021 13:10:24 -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 27674 invoked from network); 15 Dec 2021 13:10:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=avm.de; s=mail; t=1639573812; bh=VqaOwY13vLLqbPi/kjPVYGy7kN0Sc3SdTSoX7s8vjyo=; h=In-Reply-To:References:Subject:From:To:Date:From; b=buvjwyC12sCXWRIPCq8+ijkFbllBrypY56nZ33YOPDVV0bz8nFB15JrlxDHMT5aKD cUOgERt4cbdf3SYAjFy3isTJh4/nVMi0J00wmEzb/m9JRI2SjHOg5Xn5NNTYD0av0Q C6xAJwURJJPrr1pgCN/RNXtEFE9KJvEZRGKMSoKI= MIME-Version: 1.0 X-Disclaimed: 1 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: d.dorau@avm.de To: musl@lists.openwall.com Date: Wed, 15 Dec 2021 14:10:12 +0100 Message-ID: X-Mailer: Lotus Domino Web Server Release 11.0.1FP4 October 01, 2021 X-MIMETrack: Serialize by http on ANIS1/AVM(Release 11.0.1FP4|October 01, 2021) at 15.12.2021 14:10:12, Serialize complete at 15.12.2021 14:10:12, Serialize by Router on ANIS1/AVM(Release 11.0.1FP4|October 01, 2021) at 15.12.2021 14:10:12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: 149429::1639573812-0000056E-EF5204B9/0/0 X-purgate-type: clean X-purgate-size: 3405 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean Subject: [musl] Tracking shared libraries in GDB not working? 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 th= en 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=20 Remote debugging using 192.168.190.33:2345=20 Reading symbols from /home/ddorau/gu/GU=5FMASTER/filesystem=5Ftemp/usr/bin/= pbd...=20 Reading symbols from /home/ddorau/gu/GU=5FMASTER/filesystem=5Ftemp/usr/bin/= .debug/pbd...=20 Reading symbols from /home/ddorau/gu/GU=5FMASTER/filesystem=5Ftemp/lib/ld-m= usl-mips-sf.so.1...=20 Reading symbols from /home/ddorau/gu/GU=5FMASTER/filesystem=5Ftemp/lib/.deb= ug/libc.so...=20 0x77f40ee0 in =5Fdlstart () from /home/ddorau/gu/GU=5FMASTER/filesystem=5Ft= emp/lib/ld-musl-mips-sf.so.1=20 (gdb) break main=20 Breakpoint 1 at 0x55557e10: file pbserver.c, line 11668.=20 (gdb) continue Continuing. =20 Breakpoint 1, main (argc=3D1, argv=3D0x7fffd564) at pbserver.c:11668 11668 {=20 (gdb) info shared=20 >From To Syms Read Shared Object Library=20 0x77f40740 0x77fba844 Yes /home/ddorau/gu/GU=5FMASTER/filesystem= =5Ftemp/lib/ld-musl-mips-sf.so.1 If I repeat that whole process on a glibc based ARM platform, it works as e= xpected. There, gdb is able to notice all shared libraries the application was linked again= st and shows them correspondingly: (gdb) i shared = =20 >From To Syms Read Shared Object Library = =20 0xb6fcea00 0xb6fe9d90 Yes (*) /home/ddorau/gu/GU=5FMASTER/filesystem= =5Ftemp/lib/ld-linux.so.3 =20 0xb6faa168 0xb6fbbc08 Yes /home/ddorau/gu/GU=5FMASTER/filesystem= =5Ftemp/usr/lib/libbsd.so.0 =20 0xb6f956f0 0xb6f95cc8 Yes (*) /home/ddorau/gu/GU=5FMASTER/filesystem= =5Ftemp/lib/libwdt.so.1 =20 0xb6f7d0c8 0xb6f826e0 Yes (*) /home/ddorau/gu/GU=5FMASTER/filesystem= =5Ftemp/lib/libmxml.so.1 =20 0xb6f68984 0xb6f6994c Yes (*) /home/ddorau/gu/GU=5FMASTER/filesystem= =5Ftemp/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 o= f 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. Thanks Daniel