This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Fix problem with (maybe) non-relocated .opd section on powerpc64-linux
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 14 Aug 2008 19:15:33 +0200 (CEST)
- Subject: Re: [rfc] Fix problem with (maybe) non-relocated .opd section on powerpc64-linux
Daniel Jacobowitz wrote:
> On Fri, May 16, 2008 at 10:35:14PM +0200, Ulrich Weigand wrote:
> > Thinking about this, it seems this would mean that function descriptors
> > cannot work in kernel modules even today: add-symbol-file solely adds
> > an objfile (with obj_sections and so on); it does not modify the target
> > and its section table. Right?
>
> Sounds like you're right. I have never tried it, though many of our
> customers use KGDB; perhaps not the ones who use PPC64.
Another patch that I didn't get to work on for a while ...
Given that it seems object files / kernel modules will not work with the
current setup anyway, and the patch I originally proposed does fix a
serious problem with Linux shared libraries in some cases, I'd like to
just apply that patch.
Here's an updated version with additional comments to summarize this
discussion. Retested on powerpc64-linux.
Any objections to installing this patch?
Bye,
Ulrich
ChangeLog:
* ppc-linux-tdep.c (ppc64_linux_convert_from_func_ptr_addr): Read
and manually relocate .opd contents from BFD instead of reading
them from target memory.
diff -urNp gdb-orig/gdb/ppc-linux-tdep.c gdb-head/gdb/ppc-linux-tdep.c
--- gdb-orig/gdb/ppc-linux-tdep.c 2008-05-26 19:48:46.000000000 +0200
+++ gdb-head/gdb/ppc-linux-tdep.c 2008-08-14 18:00:17.398719879 +0200
@@ -601,7 +601,36 @@ ppc64_linux_convert_from_func_ptr_addr (
/* Check if ADDR points to a function descriptor. */
if (s && strcmp (s->the_bfd_section->name, ".opd") == 0)
- return get_target_memory_unsigned (targ, addr, 8);
+ {
+ /* There may be relocations that need to be applied to the .opd
+ section. Unfortunately, this function may be called at a time
+ where these relocations have not yet been performed -- this can
+ happen for example shortly after a library has been loaded with
+ dlopen, but ld.so has not yet applied the relocations.
+
+ To cope with both the case where the relocation has been applied,
+ and the case where it has not yet been applied, we do *not* read
+ the (maybe) relocated value from target memory, but we instead
+ read the non-relocated value from the BFD, and apply the relocation
+ offset manually.
+
+ This makes the assumption that all .opd entries are always relocated
+ by the same offset the section itself was relocated. This should
+ always be the case for GNU/Linux executables and shared libraries.
+ Note that other kind of object files (e.g. those added via
+ add-symbol-files) will currently never end up here anyway, as this
+ function accesses *target* sections only; only the main exec and
+ shared libraries are ever added to the target. */
+
+ gdb_byte buf[8];
+ int res;
+
+ res = bfd_get_section_contents (s->bfd, s->the_bfd_section,
+ &buf, addr - s->addr, 8);
+ if (res != 0)
+ return extract_unsigned_integer (buf, 8)
+ - bfd_section_vma (s->bfd, s->the_bfd_section) + s->addr;
+ }
return addr;
}
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com