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

[Daniel Jacobowitz <drow@false.org>]

On Thu, May 15, 2008 at 01:02:49AM +0200, Ulrich Weigand wrote:
> However, this is not the case if the library is loaded via dlopen.  In this
> case, the _dl_debug_state breakpoint is hit *before* relocations are applied.
> (I guess this might be considered a bug in glibc.  But we have to live with
> existing glibc's in the field anyway ...)

Not that I disagree with your conclusions, but this is a sorry state
of affairs.  There's a status field in struct r_debug; what is it when
this happens?  RT_ADD or RT_CONSISTENT?  RT_ADD is supposed to happen
before the object is added to the list, and RT_CONSISTENT after it has
been relocated.  We can end up loading inconsistent shared libraries,
if we're between those two points and someone does "info shared", but
this happens rarely and it's not the case here.

I feel like we've discussed this problem before, in one of the various
revisions of the same patch we were discussing yesterday, but I can't
find it.

> So to solve this I'm now completely ignoring contents of .opd in target
> memory, and instead always retrieve the contents from the BFD.  Those
> will certainly be non-relocated, so applying the relocation offset by
> hand will always result in the correct target address.
> 
> Is this a reasonable thing to do?

We went round the choice of where to read memory from several times on
the previous patch, but I don't know the details.


-- 
Daniel Jacobowitz
CodeSourcery