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