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, 15 May 2008 19:36:33 +0200 (CEST)
- Subject: Re: [rfc] Fix problem with (maybe) non-relocated .opd section on powerpc64-linux
Daniel Jacobowitz wrote:
> This makes the assumption that all .opd entries are always relocated
> by the same offset the section itself was relocated. */
>
> Do Linux kernel modules have an opd section? I'd recommend the
> routine the dwarf reader uses to apply relocations except it would be
> very inefficient unless we cached the result.
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?
Should we be using the ppc-linux-tdep.c gdbarch for that?
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?
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?
> > > We went round the choice of where to read memory from several times on
> > > the previous patch, but I don't know the details.
> >
> > OK, thanks.
>
> It looks like the main issue was making sure we did read from the
> target if the target_ops provided said to; the exception being the use
> of tmp_bfd_target in solib-svr4.c.I don't see a problem with your
> change other than the offset assumption I mentioned above.
Thanks!
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com