* [PATCH] gdbserver: Handle DT_MIPS_RLD_MAP dynamic tag
@ 2012-04-03 20:48 Maciej W. Rozycki
2012-04-03 21:27 ` Pedro Alves
2012-04-04 19:16 ` Jan Kratochvil
0 siblings, 2 replies; 6+ messages in thread
From: Maciej W. Rozycki @ 2012-04-03 20:48 UTC (permalink / raw)
To: gdb-patches
Hi,
While working on a test case for an unrelated issue I have noticed
single-stepping over system library calls is broken on the MIPS/Linux
target when `gdbserver' is used. On closer inspection I have observed
`gdbserver' reports no shared libraries loaded. Further investigation has
revealed that the newly-added support for the `qXfer:libraries-svr4:read'
packet does not handle the DT_MIPS_RLD_MAP dynamic tag and therefore
cannot locate the link map on the MIPS target.
Such support has been long present in gdb/solib-svr4.c, hence a fix
turned out rather mechanical; here's a piece of code ported from there
over to linux-low.c, likewise making no special exception just for the
MIPS platform and applying to generic code instead. This change has fixed
the single-stepping problem observed for me.
Just to be safe I have regression-tested this change for the
mips-linux-gnu remote target, o32/big-endian multilib (using an x86 Linux
host) with 139 failures removed starting from:
(gdb) PASS: gdb.base/break.exp: backtrace from factorial(5.1)
break exit
Function "exit" not defined.
(gdb) FAIL: gdb.base/break.exp: setting breakpoint at exit
and no new ones. I didn't test the change for any other target, but then
DT_MIPS_RLD_MAP tags are not expected to appear on non-MIPS binaries,
hence the "dyn->d_tag == DT_MIPS_RLD_MAP" conditional is not expected to
trigger there.
OK to apply?
2012-04-03 Maciej W. Rozycki <macro@codesourcery.com>
gdb/gdbserver/
* linux-low.c (get_r_debug): Handle DT_MIPS_RLD_MAP.
Maciej
gdb-gdbserver-rld-map.diff
Index: gdb-fsf-trunk-quilt/gdb/gdbserver/linux-low.c
===================================================================
--- gdb-fsf-trunk-quilt.orig/gdb/gdbserver/linux-low.c 2012-04-03 13:38:58.575561428 +0100
+++ gdb-fsf-trunk-quilt/gdb/gdbserver/linux-low.c 2012-04-03 13:39:17.315624148 +0100
@@ -5419,7 +5419,9 @@ get_dynamic (const int pid, const int is
}
/* Return &_r_debug in the inferior, or -1 if not present. Return value
- can be 0 if the inferior does not yet have the library list initialized. */
+ can be 0 if the inferior does not yet have the library list initialized.
+ We look for DT_MIPS_RLD_MAP first. MIPS executables use this instead of
+ DT_DEBUG, although they sometimes contain an unused DT_DEBUG entry too. */
static CORE_ADDR
get_r_debug (const int pid, const int is_elf64)
@@ -5437,6 +5439,21 @@ get_r_debug (const int pid, const int is
if (is_elf64)
{
Elf64_Dyn *const dyn = (Elf64_Dyn *) buf;
+ union
+ {
+ Elf64_Xword map;
+ unsigned char buf[sizeof (Elf64_Xword)];
+ }
+ rld_map;
+
+ if (dyn->d_tag == DT_MIPS_RLD_MAP)
+ {
+ if (linux_read_memory (dyn->d_un.d_val,
+ rld_map.buf, sizeof (rld_map.buf)) == 0)
+ return rld_map.map;
+ else
+ break;
+ }
if (dyn->d_tag == DT_DEBUG)
return dyn->d_un.d_val;
@@ -5447,6 +5464,21 @@ get_r_debug (const int pid, const int is
else
{
Elf32_Dyn *const dyn = (Elf32_Dyn *) buf;
+ union
+ {
+ Elf32_Word map;
+ unsigned char buf[sizeof (Elf32_Word)];
+ }
+ rld_map;
+
+ if (dyn->d_tag == DT_MIPS_RLD_MAP)
+ {
+ if (linux_read_memory (dyn->d_un.d_val,
+ rld_map.buf, sizeof (rld_map.buf)) == 0)
+ return rld_map.map;
+ else
+ break;
+ }
if (dyn->d_tag == DT_DEBUG)
return dyn->d_un.d_val;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdbserver: Handle DT_MIPS_RLD_MAP dynamic tag
2012-04-03 20:48 [PATCH] gdbserver: Handle DT_MIPS_RLD_MAP dynamic tag Maciej W. Rozycki
@ 2012-04-03 21:27 ` Pedro Alves
2012-04-04 11:37 ` Maciej W. Rozycki
2012-04-04 19:16 ` Jan Kratochvil
1 sibling, 1 reply; 6+ messages in thread
From: Pedro Alves @ 2012-04-03 21:27 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: gdb-patches
Hi Maciej,
On 04/03/2012 09:47 PM, Maciej W. Rozycki wrote:
> While working on a test case for an unrelated issue I have noticed
> single-stepping over system library calls is broken on the MIPS/Linux
> target when `gdbserver' is used. On closer inspection I have observed
> `gdbserver' reports no shared libraries loaded. Further investigation has
> revealed that the newly-added support for the `qXfer:libraries-svr4:read'
> packet does not handle the DT_MIPS_RLD_MAP dynamic tag and therefore
> cannot locate the link map on the MIPS target.
Yeah, I had noticed that on
<http://sourceware.org/ml/gdb-patches/2012-03/msg00142.html>, but never got
to propose a fix. Sorry about that.
> gdb-gdbserver-rld-map.diff
> Index: gdb-fsf-trunk-quilt/gdb/gdbserver/linux-low.c
> ===================================================================
> --- gdb-fsf-trunk-quilt.orig/gdb/gdbserver/linux-low.c 2012-04-03 13:38:58.575561428 +0100
> +++ gdb-fsf-trunk-quilt/gdb/gdbserver/linux-low.c 2012-04-03 13:39:17.315624148 +0100
> @@ -5419,7 +5419,9 @@ get_dynamic (const int pid, const int is
> }
>
> /* Return &_r_debug in the inferior, or -1 if not present. Return value
> - can be 0 if the inferior does not yet have the library list initialized. */
> + can be 0 if the inferior does not yet have the library list initialized.
> + We look for DT_MIPS_RLD_MAP first. MIPS executables use this instead of
> + DT_DEBUG, although they sometimes contain an unused DT_DEBUG entry too. */
>
Can that "unused DT_DEBUG" entry ever appear before DT_MIPS_RLD_MAP in the tags
list? With this patch, we'll stop looking if we see DT_DEBUG first, while
solib-svr4.c in GDB first looks for DT_MIPS_RLD_MAP in all tags, and only
if not found looks for DT_DEBUG (presumably, if there's no DT_MIPS_RLD_MAP,
then there's no DT_DEBUG either; only if DT_MIPS_RLD_MAP exist might there be
a DT_DEBUG). Do we need to worry about this?
> static CORE_ADDR
> get_r_debug (const int pid, const int is_elf64)
> @@ -5437,6 +5439,21 @@ get_r_debug (const int pid, const int is
> if (is_elf64)
> {
> Elf64_Dyn *const dyn = (Elf64_Dyn *) buf;
> + union
> + {
> + Elf64_Xword map;
> + unsigned char buf[sizeof (Elf64_Xword)];
> + }
> + rld_map;
> +
> + if (dyn->d_tag == DT_MIPS_RLD_MAP)
> + {
> + if (linux_read_memory (dyn->d_un.d_val,
> + rld_map.buf, sizeof (rld_map.buf)) == 0)
> + return rld_map.map;
> + else
> + break;
> + }
>
> if (dyn->d_tag == DT_DEBUG)
> return dyn->d_un.d_val;
> @@ -5447,6 +5464,21 @@ get_r_debug (const int pid, const int is
> else
> {
> Elf32_Dyn *const dyn = (Elf32_Dyn *) buf;
> + union
> + {
> + Elf32_Word map;
> + unsigned char buf[sizeof (Elf32_Word)];
> + }
> + rld_map;
> +
> + if (dyn->d_tag == DT_MIPS_RLD_MAP)
> + {
> + if (linux_read_memory (dyn->d_un.d_val,
> + rld_map.buf, sizeof (rld_map.buf)) == 0)
> + return rld_map.map;
> + else
> + break;
> + }
>
> if (dyn->d_tag == DT_DEBUG)
> return dyn->d_un.d_val;
--
Pedro Alves
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdbserver: Handle DT_MIPS_RLD_MAP dynamic tag
2012-04-03 21:27 ` Pedro Alves
@ 2012-04-04 11:37 ` Maciej W. Rozycki
2012-04-04 11:55 ` Pedro Alves
0 siblings, 1 reply; 6+ messages in thread
From: Maciej W. Rozycki @ 2012-04-04 11:37 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
Hi Pedro,
> Yeah, I had noticed that on
> <http://sourceware.org/ml/gdb-patches/2012-03/msg00142.html>, but never got
> to propose a fix. Sorry about that.
Well, I'm supposed to catch this kind of breakage myself these days. ;)
> > Index: gdb-fsf-trunk-quilt/gdb/gdbserver/linux-low.c
> > ===================================================================
> > --- gdb-fsf-trunk-quilt.orig/gdb/gdbserver/linux-low.c 2012-04-03 13:38:58.575561428 +0100
> > +++ gdb-fsf-trunk-quilt/gdb/gdbserver/linux-low.c 2012-04-03 13:39:17.315624148 +0100
> > @@ -5419,7 +5419,9 @@ get_dynamic (const int pid, const int is
> > }
> >
> > /* Return &_r_debug in the inferior, or -1 if not present. Return value
> > - can be 0 if the inferior does not yet have the library list initialized. */
> > + can be 0 if the inferior does not yet have the library list initialized.
> > + We look for DT_MIPS_RLD_MAP first. MIPS executables use this instead of
> > + DT_DEBUG, although they sometimes contain an unused DT_DEBUG entry too. */
>
> Can that "unused DT_DEBUG" entry ever appear before DT_MIPS_RLD_MAP in the tags
> list? With this patch, we'll stop looking if we see DT_DEBUG first, while
> solib-svr4.c in GDB first looks for DT_MIPS_RLD_MAP in all tags, and only
> if not found looks for DT_DEBUG (presumably, if there's no DT_MIPS_RLD_MAP,
> then there's no DT_DEBUG either; only if DT_MIPS_RLD_MAP exist might there be
> a DT_DEBUG). Do we need to worry about this?
Hmm, I've double-checked the sources and as you say solib-svr4.c does not
rely on the order of the tags indeed. I got mislead by the comment in
MIPS BFD that says:
/* SGI object has the equivalence of DT_DEBUG in the
DT_MIPS_RLD_MAP entry. This must come first because glibc
only fills in DT_MIPS_RLD_MAP (not DT_DEBUG) and GDB only
looks at the first one it sees. */
and which obviously does not stand (anymore?) as far as GDB is concerned.
I'll post a proposal to update it to match reality. It is worth noting
that current MIPS BFD always adds DT_DEBUG too (and always after
DT_MIPS_RLD_MAP, the comment gets this part right).
Anyway, I think `gdbserver' should be as liberal as to what it accepts as
GDB itself is, so I have updated my change as below. No changes in
regression testing.
Thanks for your input. Any further comments?
2012-04-03 Maciej W. Rozycki <macro@codesourcery.com>
gdb/gdbserver/
* linux-low.c (get_r_debug): Handle DT_MIPS_RLD_MAP.
Maciej
gdb-gdbserver-rld-map.diff
Index: gdb-fsf-trunk-quilt/gdb/gdbserver/linux-low.c
===================================================================
--- gdb-fsf-trunk-quilt.orig/gdb/gdbserver/linux-low.c 2012-04-03 16:49:32.000000000 +0100
+++ gdb-fsf-trunk-quilt/gdb/gdbserver/linux-low.c 2012-04-04 11:56:37.405566578 +0100
@@ -5419,7 +5419,9 @@ get_dynamic (const int pid, const int is
}
/* Return &_r_debug in the inferior, or -1 if not present. Return value
- can be 0 if the inferior does not yet have the library list initialized. */
+ can be 0 if the inferior does not yet have the library list initialized.
+ We look for DT_MIPS_RLD_MAP first. MIPS executables use this instead of
+ DT_DEBUG, although they sometimes contain an unused DT_DEBUG entry too. */
static CORE_ADDR
get_r_debug (const int pid, const int is_elf64)
@@ -5427,19 +5429,35 @@ get_r_debug (const int pid, const int is
CORE_ADDR dynamic_memaddr;
const int dyn_size = is_elf64 ? sizeof (Elf64_Dyn) : sizeof (Elf32_Dyn);
unsigned char buf[sizeof (Elf64_Dyn)]; /* The larger of the two. */
+ CORE_ADDR map = -1;
dynamic_memaddr = get_dynamic (pid, is_elf64);
if (dynamic_memaddr == 0)
- return (CORE_ADDR) -1;
+ return map;
while (linux_read_memory (dynamic_memaddr, buf, dyn_size) == 0)
{
if (is_elf64)
{
Elf64_Dyn *const dyn = (Elf64_Dyn *) buf;
+ union
+ {
+ Elf64_Xword map;
+ unsigned char buf[sizeof (Elf64_Xword)];
+ }
+ rld_map;
- if (dyn->d_tag == DT_DEBUG)
- return dyn->d_un.d_val;
+ if (dyn->d_tag == DT_MIPS_RLD_MAP)
+ {
+ if (linux_read_memory (dyn->d_un.d_val,
+ rld_map.buf, sizeof (rld_map.buf)) == 0)
+ return rld_map.map;
+ else
+ break;
+ }
+
+ if (dyn->d_tag == DT_DEBUG && map == -1)
+ map = dyn->d_un.d_val;
if (dyn->d_tag == DT_NULL)
break;
@@ -5447,9 +5465,24 @@ get_r_debug (const int pid, const int is
else
{
Elf32_Dyn *const dyn = (Elf32_Dyn *) buf;
+ union
+ {
+ Elf32_Word map;
+ unsigned char buf[sizeof (Elf32_Word)];
+ }
+ rld_map;
- if (dyn->d_tag == DT_DEBUG)
- return dyn->d_un.d_val;
+ if (dyn->d_tag == DT_MIPS_RLD_MAP)
+ {
+ if (linux_read_memory (dyn->d_un.d_val,
+ rld_map.buf, sizeof (rld_map.buf)) == 0)
+ return rld_map.map;
+ else
+ break;
+ }
+
+ if (dyn->d_tag == DT_DEBUG && map == -1)
+ map = dyn->d_un.d_val;
if (dyn->d_tag == DT_NULL)
break;
@@ -5458,7 +5491,7 @@ get_r_debug (const int pid, const int is
dynamic_memaddr += dyn_size;
}
- return (CORE_ADDR) -1;
+ return map;
}
/* Read one pointer from MEMADDR in the inferior. */
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdbserver: Handle DT_MIPS_RLD_MAP dynamic tag
2012-04-04 11:37 ` Maciej W. Rozycki
@ 2012-04-04 11:55 ` Pedro Alves
2012-04-10 22:54 ` Maciej W. Rozycki
0 siblings, 1 reply; 6+ messages in thread
From: Pedro Alves @ 2012-04-04 11:55 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: gdb-patches
On 04/04/2012 12:36 PM, Maciej W. Rozycki wrote:
> Anyway, I think `gdbserver' should be as liberal as to what it accepts as
> GDB itself is, so I have updated my change as below. No changes in
> regression testing.
>
> Thanks for your input. Any further comments?
Nope. Looks good to me.
Thanks,
--
Pedro Alves
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdbserver: Handle DT_MIPS_RLD_MAP dynamic tag
2012-04-03 20:48 [PATCH] gdbserver: Handle DT_MIPS_RLD_MAP dynamic tag Maciej W. Rozycki
2012-04-03 21:27 ` Pedro Alves
@ 2012-04-04 19:16 ` Jan Kratochvil
1 sibling, 0 replies; 6+ messages in thread
From: Jan Kratochvil @ 2012-04-04 19:16 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: gdb-patches
On Tue, 03 Apr 2012 22:47:28 +0200, Maciej W. Rozycki wrote:
> gdb/gdbserver/
> * linux-low.c (get_r_debug): Handle DT_MIPS_RLD_MAP.
Thanks for catching it, I only recently got MIPS access for it but did not yet
get to it.
Jan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdbserver: Handle DT_MIPS_RLD_MAP dynamic tag
2012-04-04 11:55 ` Pedro Alves
@ 2012-04-10 22:54 ` Maciej W. Rozycki
0 siblings, 0 replies; 6+ messages in thread
From: Maciej W. Rozycki @ 2012-04-10 22:54 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
On Wed, 4 Apr 2012, Pedro Alves wrote:
> Nope. Looks good to me.
Applied now, thanks for your review.
Maciej
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-04-10 22:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-03 20:48 [PATCH] gdbserver: Handle DT_MIPS_RLD_MAP dynamic tag Maciej W. Rozycki
2012-04-03 21:27 ` Pedro Alves
2012-04-04 11:37 ` Maciej W. Rozycki
2012-04-04 11:55 ` Pedro Alves
2012-04-10 22:54 ` Maciej W. Rozycki
2012-04-04 19:16 ` Jan Kratochvil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox