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

[Daniel Jacobowitz <drow@false.org>]

On Thu, May 15, 2008 at 07:36:33PM +0200, Ulrich Weigand wrote:
> Kernel modules generally have an opd section; as in other object files,
> these will carry a R_PPC64_ADDR64 relocation pointing to .text + some
> offset.  (In shared libraries we see a R_PPC_RELATIVE instead.)
> 
> That means my heuristics will probably go wrong when applied to an
> object file (or kernel module).  When would that actually happen?

Generally, they are loaded with either add-symbol-file (by hand or
autogenerated) specifying each section.  The KGDB guys also have a GDB
patch to do it automatically.  That's one of my targetted applications
of Python scripting.

> Should we be using the ppc-linux-tdep.c gdbarch for that?

It's a toss-up.  I think yes; either that, or the function descriptor
code has to move somewhere else that it would still be used, since it
still applies.

> I guess we could cache the result of symfile_relocate_debug_section
> on the .opd section for the objfile.  One minor issue would be that
> this function currently refuses to operate on non-SEC_DEBUGGING
> sections -- is there a reason for that?

Not that I can remember.

> As I understand symfile_relocate_debug_section, this would still *not*
> take the load address of a shared library into account, so that part
> would still need to be applied manually, right?

I believe so - ANOFFSET?


-- 
Daniel Jacobowitz
CodeSourcery