Re: [rfc] Fix problem with (maybe) non-relocated .opd section on powerpc64-linux

["Ulrich Weigand" <uweigand@de.ibm.com>]

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