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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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