mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Tracking shared libraries in GDB not working?
@ 2021-12-15 13:10 d.dorau
  2021-12-15 15:20 ` Rich Felker
  2021-12-20  8:54 ` d.dorau
  0 siblings, 2 replies; 4+ messages in thread
From: d.dorau @ 2021-12-15 13:10 UTC (permalink / raw)
  To: musl

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.

Thanks
Daniel


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Tracking shared libraries in GDB not working?
  2021-12-15 13:10 [musl] Tracking shared libraries in GDB not working? d.dorau
@ 2021-12-15 15:20 ` Rich Felker
  2021-12-20  8:54 ` d.dorau
  1 sibling, 0 replies; 4+ messages in thread
From: Rich Felker @ 2021-12-15 15:20 UTC (permalink / raw)
  To: d.dorau; +Cc: musl

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Tracking shared libraries in GDB not working?
  2021-12-15 13:10 [musl] Tracking shared libraries in GDB not working? d.dorau
  2021-12-15 15:20 ` Rich Felker
@ 2021-12-20  8:54 ` d.dorau
  2022-01-09  5:14   ` Rich Felker
  1 sibling, 1 reply; 4+ messages in thread
From: d.dorau @ 2021-12-20  8:54 UTC (permalink / raw)
  To: musl; +Cc: Rich Felker

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
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Tracking shared libraries in GDB not working?
  2021-12-20  8:54 ` d.dorau
@ 2022-01-09  5:14   ` Rich Felker
  0 siblings, 0 replies; 4+ messages in thread
From: Rich Felker @ 2022-01-09  5:14 UTC (permalink / raw)
  To: d.dorau; +Cc: musl

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Mon, Dec 20, 2021 at 09:54:40AM +0100, d.dorau@avm.de wrote:
> 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.

Thanks! This patch is not correct as-is, because the value of
DT_MIPS_RLD_MAP_REL is only meaningful on mips and could be reused on
other archs. But I've whipped up what I think is a correct version of
it here (attached), using the same approach as used for
DT_MIPS_RLD_MAP already. If you get a chance, please let me know if it
works.

Rich

[-- Attachment #2: mips_pie_debug.diff --]
[-- Type: text/plain, Size: 2021 bytes --]

diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h
index 88d23639..f4023b16 100644
--- a/arch/mips/reloc.h
+++ b/arch/mips/reloc.h
@@ -29,6 +29,7 @@
 
 #define NEED_MIPS_GOT_RELOCS 1
 #define DT_DEBUG_INDIRECT DT_MIPS_RLD_MAP
+#define DT_DEBUG_INDIRECT_REL DT_MIPS_RLD_MAP_REL
 #define ARCH_SYM_REJECT_UND(s) (!((s)->st_other & STO_MIPS_PLT))
 
 #define CRTJMP(pc,sp) __asm__ __volatile__( \
diff --git a/arch/mips64/reloc.h b/arch/mips64/reloc.h
index fdb5edc9..145d8b0b 100644
--- a/arch/mips64/reloc.h
+++ b/arch/mips64/reloc.h
@@ -38,6 +38,7 @@
 
 #define NEED_MIPS_GOT_RELOCS 1
 #define DT_DEBUG_INDIRECT DT_MIPS_RLD_MAP
+#define DT_DEBUG_INDIRECT_REL DT_MIPS_RLD_MAP_REL
 #define ARCH_SYM_REJECT_UND(s) (!((s)->st_other & STO_MIPS_PLT))
 
 #define CRTJMP(pc,sp) __asm__ __volatile__( \
diff --git a/arch/mipsn32/reloc.h b/arch/mipsn32/reloc.h
index 47c6e591..bf00bd6a 100644
--- a/arch/mipsn32/reloc.h
+++ b/arch/mipsn32/reloc.h
@@ -29,6 +29,7 @@
 
 #define NEED_MIPS_GOT_RELOCS 1
 #define DT_DEBUG_INDIRECT DT_MIPS_RLD_MAP
+#define DT_DEBUG_INDIRECT_REL DT_MIPS_RLD_MAP_REL
 #define ARCH_SYM_REJECT_UND(s) (!((s)->st_other & STO_MIPS_PLT))
 
 #define CRTJMP(pc,sp) __asm__ __volatile__( \
diff --git a/ldso/dynlink.c b/ldso/dynlink.c
index 5b9c8be4..93615cb6 100644
--- a/ldso/dynlink.c
+++ b/ldso/dynlink.c
@@ -1923,6 +1923,10 @@ void __dls3(size_t *sp, size_t *auxv)
 			size_t *ptr = (size_t *) app.dynv[i+1];
 			*ptr = (size_t)&debug;
 		}
+		if (app.dynv[i]==DT_DEBUG_INDIRECT_REL) {
+			size_t *ptr = (size_t *)((size_t)&app.dynv[i] + app.dynv[i+1]);
+			*ptr = (size_t)&debug;
+		}
 	}
 
 	/* This must be done before final relocations, since it calls
diff --git a/src/internal/dynlink.h b/src/internal/dynlink.h
index 51c0639f..d37ebbaa 100644
--- a/src/internal/dynlink.h
+++ b/src/internal/dynlink.h
@@ -92,6 +92,10 @@ struct fdpic_dummy_loadmap {
 #define DT_DEBUG_INDIRECT 0
 #endif
 
+#ifndef DT_DEBUG_INDIRECT_REL
+#define DT_DEBUG_INDIRECT_REL 0
+#endif
+
 #define AUX_CNT 32
 #define DYN_CNT 32
 

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-01-09  5:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-15 13:10 [musl] Tracking shared libraries in GDB not working? d.dorau
2021-12-15 15:20 ` Rich Felker
2021-12-20  8:54 ` d.dorau
2022-01-09  5:14   ` Rich Felker

Code repositories for project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).