This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: prelink test failure on hurd


On Mon, Mar 07, 2011 at 11:11:19AM -0800, Roland McGrath wrote:
> That's all using directly-supplied data.  So it should not depend on the
> host circumstances at all.  If it does, that suggests some curious bug.
> So the place I would start is comparing things between the host where
> things all work and the host where things don't all work.
> 
> First, look at the libdwfl registration of the modules.  For that, I'd use
> src/unstrip -n -M testmaps54-32.  The output of that should match on every
> host, since it only depends on the contents of the testmaps54-32 file.  If
> there are differences there, then that might explain everything else.

That outputs the same.

> If that has no differences, then the next suspicion would be in the
> address_sync calculations.  Debug the dwfl_module_getdwarf.c code where
> the address_sync fields get set, and see if these are coming out
> differently between the working and non-working hosts.

The first weird thing I see is:
Breakpoint 5, find_debuginfo (mod=0x804ebb0) at
dwfl_module_getdwarf.c:555
555       if (result == DWFL_E_NOERROR && mod->debug.address_sync
!= 0)
(gdb) p result
$13 = 1073938454
(gdb) p /x result
$14 = 0x40030016

Which seems to be caused by this code:
open_elf (Dwfl_Module *mod, struct dwfl_file *file)
{
  if (file->elf == NULL)
    {
      /* If there was a pre-primed file name left that the callback left
         behind, try to open that file name.  */
      if (file->fd < 0 && file->name != NULL)
        file->fd = TEMP_FAILURE_RETRY (open64 (file->name, O_RDONLY));

      if (file->fd < 0)
        return CBFAIL;

(gdb) p *file
$28 = {name = 0x0, fd = -1, valid = false, relocated = false, elf = 0x0,
  vaddr = 0, address_sync = 0}
(gdb) p errno
$29 = 1073741902
(gdb) p /x errno
$30 = 0x4000004e

Which gets turned in the result above.

That seems to be the hurd error code for ENOSYS.  I see no reason
why it's returning ENOSYS currently.  But we probably shouldn't be
doing anything with errno at this time since we didn't even try
to open the file.

Anyway, on the other host I get DWFL_E_CB in result instead.

When we get back in find_symtab(), the failing host gets:
        default:
          return;

The working host gets:
        case DWFL_E_CB:         /* The find_debuginfo hook failed.  */
          mod->symerr = DWFL_E_NO_SYMTAB;
          break;
[...]
          find_dynsym (mod);
          return;



Kurt


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]