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
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