[RFA/solib-svr4] use AT_BASE auxiliary entry to compute load base address

[RFA/solib-svr4] use AT_BASE auxiliary entry to compute load base address

[Joel Brobecker]

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

Hello,

I came across an unexpected issue on sparc-solaris 2.9, where I tried
to attach to an Ada program. When I later did a "continue", the debugger
error'ed out saying:

    (gdb) c
    Continuing.
    Warning:
    Cannot insert breakpoint -1.
    Error accessing memory address 0xff36159c: I/O error.

Breakpoint -1 here corresponds to the shlib breakpoint:

    (gdb) maintenance info breakpoints 
    Num Type           Disp Enb Address    What
    -1  shlib events   keep y   0xff36159c 

I think that the problem is that we're computing the wrong base load
address in solib-svr4.c. As it turned out, there was a "TODO" hint
added by Daniel that suggested using the AT_BASE auxiliary entry.
The attached patch attempts to do that.

2007-09-12  Joel Brobecker  <brobecker@adacore.com>

        * solib-svr4.c: Add include of "auxv.h".
        (enable_break): Use the AT_BASE auxiliary entry if available.
        * Makefile.in (solib-svr4.o): Update dependencies.

Tested on x86-linux, no regression. Currently testing on sparc-solaris,
but it's taking a loooong time because sigstep is keeps timing out to
death. It fixes the issue above, and I'm confident the results will be OK.

OK to apply?

Thanks,
-- 
Joel

[-- Attachment #2: solib-svr4.diff --]
[-- Type: text/plain, Size: 2653 bytes --]

Index: solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.75
diff -u -p -r1.75 solib-svr4.c
--- solib-svr4.c	23 Aug 2007 18:08:38 -0000	1.75
+++ solib-svr4.c	12 Sep 2007 21:03:39 -0000
@@ -41,6 +41,7 @@
 #include "bfd-target.h"
 #include "elf-bfd.h"
 #include "exec.h"
+#include "auxv.h"
 
 static struct link_map_offsets *svr4_fetch_link_map_offsets (void);
 static int svr4_have_link_map_offsets (void);
@@ -1008,11 +1009,6 @@ enable_break (void)
          be trivial on GNU/Linux).  Therefore, we have to try an alternate
          mechanism to find the dynamic linker's base address.  */
 
-      /* TODO drow/2006-09-12: This is somewhat fragile, because it
-	 relies on read_pc.  On both Solaris and GNU/Linux we can use
-	 the AT_BASE auxilliary entry, which GDB now knows how to
-	 access, to find the base address.  */
-
       tmp_fd = solib_open (buf, &tmp_pathname);
       if (tmp_fd >= 0)
 	tmp_bfd = bfd_fopen (tmp_pathname, gnutarget, FOPEN_RB, tmp_fd);
@@ -1048,9 +1044,19 @@ enable_break (void)
 	  so = so->next;
 	}
 
+      /* If we were not able to find the base address of the loader
+         from our so_list, then try using the AT_BASE auxilliary entry.  */
+      if (!load_addr_found)
+        if (target_auxv_search (&current_target, AT_BASE, &load_addr) > 0)
+          load_addr_found = 1;
+
       /* Otherwise we find the dynamic linker's base address by examining
 	 the current pc (which should point at the entry point for the
-	 dynamic linker) and subtracting the offset of the entry point.  */
+	 dynamic linker) and subtracting the offset of the entry point.
+
+         This is more fragile than the previous approaches, but is a good
+         fallback method because it has actually been working well in
+         most cases.  */
       if (!load_addr_found)
 	{
 	  load_addr = (read_pc ()
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.936
diff -u -p -r1.936 Makefile.in
--- Makefile.in	5 Sep 2007 00:14:02 -0000	1.936
+++ Makefile.in	12 Sep 2007 21:03:07 -0000
@@ -2622,7 +2622,7 @@ solib-svr4.o: solib-svr4.c $(defs_h) $(e
 	$(elf_mips_h) $(symtab_h) $(bfd_h) $(symfile_h) $(objfiles_h) \
 	$(gdbcore_h) $(target_h) $(inferior_h) $(gdb_assert_h) \
 	$(solist_h) $(solib_h) $(solib_svr4_h) $(bfd_target_h) $(elf_bfd_h) \
-	$(exec_h)
+	$(exec_h) $(auxv_h)
 solib-target.o: solib-target.c $(defs_h) $(objfiles_h) $(solist_h) \
 	$(symtab_h) $(symfile_h) $(target_h) $(vec_h) $(xml_support_h) \
 	$(gdb_string_h)

Re: [RFA/solib-svr4] use AT_BASE auxiliary entry to compute load base address

[Joel Brobecker]

> 2007-09-12  Joel Brobecker  <brobecker@adacore.com>
> 
>         * solib-svr4.c: Add include of "auxv.h".
>         (enable_break): Use the AT_BASE auxiliary entry if available.
>         * Makefile.in (solib-svr4.o): Update dependencies.
> 
> Tested on x86-linux, no regression. Currently testing on sparc-solaris,
> but it's taking a loooong time because sigstep is keeps timing out to
> death. It fixes the issue above, and I'm confident the results will be OK.

Just for the record: Testing just finished and confirmed no regression
on sparc-solaris either.

-- 
Joel

Re: [RFA/solib-svr4] use AT_BASE auxiliary entry to compute load base address

[Daniel Jacobowitz]

On Wed, Sep 12, 2007 at 02:18:05PM -0700, Joel Brobecker wrote:
> Hello,
> 
> I came across an unexpected issue on sparc-solaris 2.9, where I tried
> to attach to an Ada program. When I later did a "continue", the debugger
> error'ed out saying:
> 
>     (gdb) c
>     Continuing.
>     Warning:
>     Cannot insert breakpoint -1.
>     Error accessing memory address 0xff36159c: I/O error.

So, it has attached to the program and decided that it's at the start
address.  That means we tried this:

      /* On a running target, we can get the dynamic linker's base
         address from the shared library table.  */
      solib_add (NULL, 0, &current_target, auto_solib_add);
      so = master_so_list ();
      while (so)
...

and did not find any loaded libraries or else did not find the
interpreter in the list.  That's strange and almost certainly
indicates a bug that we should fix.  The loader should have
been in the list at that point.  Maybe it has a different
filename in the list than in .interp?

If you have time, I would recommend looking into this more.

> I think that the problem is that we're computing the wrong base load
> address in solib-svr4.c. As it turned out, there was a "TODO" hint
> added by Daniel that suggested using the AT_BASE auxiliary entry.
> The attached patch attempts to do that.
> 
> 2007-09-12  Joel Brobecker  <brobecker@adacore.com>
> 
>         * solib-svr4.c: Add include of "auxv.h".
>         (enable_break): Use the AT_BASE auxiliary entry if available.
>         * Makefile.in (solib-svr4.o): Update dependencies.

This patch, independently, is a good idea and I'm glad you did it.
It's OK.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA/solib-svr4] use AT_BASE auxiliary entry to compute load base address

[Joel Brobecker]

> and did not find any loaded libraries or else did not find the
> interpreter in the list.  That's strange and almost certainly
> indicates a bug that we should fix.  The loader should have
> been in the list at that point.  Maybe it has a different
> filename in the list than in .interp?

Hmmm, that does ring a bell. I think we discussed another symptom
of the same problem:

    (gdb) start
    Breakpoint 1 at 0x2d100: file a_test.adb, line 4.
    Starting program: /[...]/a_test
    warning: Temporarily disabling breakpoints for unloaded shared library "/usr/lib/ld.so.1"

(that was on gdb@ around Mar, 11th 2007)

> > I think that the problem is that we're computing the wrong base load
> > address in solib-svr4.c. As it turned out, there was a "TODO" hint
> > added by Daniel that suggested using the AT_BASE auxiliary entry.
> > The attached patch attempts to do that.
> > 
> > 2007-09-12  Joel Brobecker  <brobecker@adacore.com>
> > 
> >         * solib-svr4.c: Add include of "auxv.h".
> >         (enable_break): Use the AT_BASE auxiliary entry if available.
> >         * Makefile.in (solib-svr4.o): Update dependencies.
> 
> This patch, independently, is a good idea and I'm glad you did it.
> It's OK.

Thanks. Checked in.

-- 
Joel

Re: [RFA/solib-svr4] use AT_BASE auxiliary entry to compute load base address

[Daniel Jacobowitz]

On Mon, Sep 17, 2007 at 12:42:13PM -0700, Joel Brobecker wrote:
> > and did not find any loaded libraries or else did not find the
> > interpreter in the list.  That's strange and almost certainly
> > indicates a bug that we should fix.  The loader should have
> > been in the list at that point.  Maybe it has a different
> > filename in the list than in .interp?
> 
> Hmmm, that does ring a bell. I think we discussed another symptom
> of the same problem:
> 
>     (gdb) start
>     Breakpoint 1 at 0x2d100: file a_test.adb, line 4.
>     Starting program: /[...]/a_test
>     warning: Temporarily disabling breakpoints for unloaded shared library "/usr/lib/ld.so.1"
> 
> (that was on gdb@ around Mar, 11th 2007)

Ah, that's why it sounded familiar.  Yes, this is likely to be the
same thing.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA/solib-svr4] use AT_BASE auxiliary entry to compute load base address

[Ulrich Weigand]

Joel Brobecker wrote:

> 2007-09-12  Joel Brobecker  <brobecker@adacore.com>
> 
>         * solib-svr4.c: Add include of "auxv.h".
>         (enable_break): Use the AT_BASE auxiliary entry if available.
>         * Makefile.in (solib-svr4.o): Update dependencies.
> 
> Tested on x86-linux, no regression. Currently testing on sparc-solaris,
> but it's taking a loooong time because sigstep is keeps timing out to
> death. It fixes the issue above, and I'm confident the results will be OK.

It looks like this breaks remote debugging in the presence of prelinking.

The problem is that AT_BASE is set by the kernel to the load bias (i.e.
the difference between the actual load address and the load address as
recorded in the ELF file) of the dynamic interpreter.  GDB goes on to
add back the load address from the ELF file, so that looks fine.

However, when doing remote debugging, the ELF file GDB sees may be
different from the ELF file that was used on the remote target.  This
happens in particular if a background prelinking job runs from time
to time on the remote system.

GDB used to work correctly in the presence of prelinking anyway,
because for regular shared libraries it detected that mismatch by
comparing the load addresses from the BFD it reads with those 
recorded in the dynamic loader's data structures (LM_ADDR_CHECK),
and adjusting its expectations if it detects prelinking.

However, this does not work for enable_break because this function
must work *before* the dynamic loader gets a chance to set up those
data structures.

Any suggestions how this could be fixed?

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFA/solib-svr4] use AT_BASE auxiliary entry to compute load base address

[Daniel Jacobowitz]

On Thu, Apr 17, 2008 at 05:11:38PM +0200, Ulrich Weigand wrote:
> GDB used to work correctly in the presence of prelinking anyway,
> because for regular shared libraries it detected that mismatch by
> comparing the load addresses from the BFD it reads with those 
> recorded in the dynamic loader's data structures (LM_ADDR_CHECK),
> and adjusting its expectations if it detects prelinking.

Can we read the dynamic linker's ELF header from the target, to
compare?

Wait, no, we can't... if we knew where it was loaded we wouldn't
need AT_BASE.  Well, we could ask gdbserver to read from the
target filesystem for us...

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA/solib-svr4] use AT_BASE auxiliary entry to compute load base address

[Ulrich Weigand]

Daniel Jacobowitz wrote:
> On Thu, Apr 17, 2008 at 05:11:38PM +0200, Ulrich Weigand wrote:
> > GDB used to work correctly in the presence of prelinking anyway,
> > because for regular shared libraries it detected that mismatch by
> > comparing the load addresses from the BFD it reads with those 
> > recorded in the dynamic loader's data structures (LM_ADDR_CHECK),
> > and adjusting its expectations if it detects prelinking.
> 
> Can we read the dynamic linker's ELF header from the target, to
> compare?
> 
> Wait, no, we can't... if we knew where it was loaded we wouldn't
> need AT_BASE.  Well, we could ask gdbserver to read from the
> target filesystem for us...

Yes, that's on my to-do list anyway ...

However, even that would not fix the same issue with core files
(if prelink changed a library between core file generation and 
use in GDB).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFA/solib-svr4] use AT_BASE auxiliary entry to compute load base address

[Daniel Jacobowitz]

On Thu, Apr 17, 2008 at 11:31:18PM +0200, Ulrich Weigand wrote:
> Yes, that's on my to-do list anyway ...
> 
> However, even that would not fix the same issue with core files
> (if prelink changed a library between core file generation and 
> use in GDB).

Drat.  And even if that bit is in the core file (likely on at least
some vendor kernels; program headers are in the same page as the
build-id note) we would not know where to look for it.

I don't want to revert the patch, since it fixes a nasty breakage
if you connect to a program when it has just started running but
has gone a few instructions, i.e. the library list is not filled in
yet but the PC is not the dynamic linker entry point.  Is there
really no way to differentiate these two cases?

-- 
Daniel Jacobowitz
CodeSourcery