Re: [RFC] - Patch for 32-bit x86 corefiles read by 64 bit gdb

[Daniel Jacobowitz <drow at false dot org>]

On Mon, Mar 05, 2007 at 10:53:25AM -0700, Fred Fish wrote:
> Notice the warning:
> 
>     warning: Can't read pathname for load map: Input/output error.
> 
> The problem here is that there is an extra shared object referenced in
> the dynamic linker's list, for which the actual name string is located
> in the address space of one of the other two libraries that haven't
> been loaded yet.  So gdb doesn't know how to find the name string.  It
> gives I/O error as it's generic response to being asked to read an
> unmapped address.
> 
> Interestingly, once you've loaded libc and ld-linux.so, you can access
> that address, but there is a null string there.  The address is also
> the same address as the first entry in the list, which is for the
> main program, and is skipped during the building of gdb's internal
> list of shared objects.
> 
> I've not dug far enough to know what this extra unnamed object is.
> But is seems intuitive that if it has the same address for the name
> string as the first (skipped) object, it should probably be skipped
> also.

(gdb) set $l = (struct link_map *)0xf7fff4f8
(gdb) p *$l
$4 = {l_addr = 0, l_name = 0xf7ffcc56 "", l_ld = 0x8049474, l_next =
0xf7fe8838, l_prev = 0x0}
(gdb) p *$l.l_next
$5 = {l_addr = 0, l_name = 0xf7ffcc56 "", l_ld = 0xffffe744, l_next =
0xf7fe8ab0, l_prev = 0xf7fff4f8}
(gdb) p *$l.l_next.l_next

The object is in the top page of virtual memory; therefore it is the
kernel-supplied vDSO.  They have the same name because they come from
these calls:

      /* Create a link_map for the executable itself.
         This will be what dlopen on "" returns.  */
      main_map = _dl_new_object ((char *) "", "", lt_executable, NULL,
                                 __RTLD_OPENEXEC, LM_ID_BASE);

...

  /* Set up the data structures for the system-supplied DSO early,
     so they can influence _dl_init_paths.  */
  if (GLRO(dl_sysinfo_dso) != NULL)
    {
      /* Do an abridged version of the work _dl_map_object_from_fd
      would do
         to map in the object.  It's already mapped and prelinked (and
         better be, since it's read-only and so we couldn't relocate
	 it).
         We just want our data structures to describe it as if we had
	 just
         mapped and relocated it normally.  */
      struct link_map *l = _dl_new_object ((char *) "", "",
      lt_library, NULL,
                                           0, LM_ID_BASE);


GCC and GNU ld optimize the empty string so that ld.so only has one
copy.  So, you're basically getting lucky.  Therefore I think your
patch is not correct.  It would be nice to find another way to get rid
of the warning, though.  Does the warning add value in any reasonably
likely situation?  If something has scribbled on the shared library
list, the next/prev pointers are more likely to be bad.


-- 
Daniel Jacobowitz
CodeSourcery