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 18:14:50 +0200 (CEST)
- Subject: Re: [rfc] Fix problem with (maybe) non-relocated .opd section on powerpc64-linux
Daniel Jacobowitz wrote:
> 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.
Well, it seems that this field is set to RT_CONSISTENT *before* the
objects are relocated (from elf/dl-open.c):
/* Notify the debugger all new objects are now ready to go. */
struct r_debug *r = _dl_debug_initialize (0, args->nsid);
r->r_state = RT_CONSISTENT;
_dl_debug_state ();
/* Only do lazy relocation if `LD_BIND_NOW' is not set. */
lazy = (mode & RTLD_BINDING_MASK) == RTLD_LAZY && GLRO(dl_lazy);
/* Relocate the objects loaded. We do this in reverse order so that copy
relocs of earlier objects overwrite the data written by later objects. */
struct link_map *l = new;
while (l->l_next)
l = l->l_next;
while (1)
{
if (! l->l_real->l_relocated)
{
#ifdef SHARED
if (__builtin_expect (GLRO(dl_profile) != NULL, 0))
{
/* If this here is the shared object which we want to profile
make sure the profile is started. We can find out whether
this is necessary or not by observing the `_dl_profile_map'
variable. If was NULL but is not NULL afterwars we must
start the profiling. */
struct link_map *old_profile_map = GL(dl_profile_map);
_dl_relocate_object (l, l->l_scope, 1, 1);
if (old_profile_map == NULL && GL(dl_profile_map) != NULL)
{
/* We must prepare the profiling. */
_dl_start_profile ();
/* Prevent unloading the object. */
GL(dl_profile_map)->l_flags_1 |= DF_1_NODELETE;
}
}
else
#endif
_dl_relocate_object (l, l->l_scope, lazy, 0);
}
if (l == new)
break;
l = l->l_prev;
}
> > 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.
OK, thanks.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com