[davidm@napali.hpl.hp.com: readelf question]

["H. J. Lu" <hjl at lucon dot org>]

Roland, do you know anything about this?


H.J.
----- Forwarded message from David Mosberger <davidm@napali.hpl.hp.com> -----

Delivered-To: hjl@localhost.lucon.org
From: David Mosberger <davidm@napali.hpl.hp.com>
Date: Fri, 13 Jun 2003 00:00:39 -0700
To: "H. J. Lu" <hjl@lucon.org>
Cc: davidm@napali.hpl.hp.com
Subject: readelf question
X-Mailer: VM 7.07 under Emacs 21.2.1
Reply-To: davidm@hpl.hp.com
X-URL: http://www.hpl.hp.com/personal/David_Mosberger/

Hi HJ,

Another toolchain question: with the latest 2.5 kernel, coredumps will
cover the kernel shared library describing the gate page (aka "gate
DSO").  Unfortunately, readelf -a prints a warning message when
reading such coredumps:

$ readelf -a core
readelf: Error: Unable to seek to 24180 for symbols
readelf: Error: Unable to seek to 24330 for dynamic string table
readelf: Error: Unable to seek to start of dynamic informationELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              CORE (Core file)
  Machine:                           Intel IA-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         10
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 0

There are no sections in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x0000000000000270 0x0000000000000000 0x0000000000000000
                 0x0000000000001c20 0x0000000000000000         0
  LOAD           0x0000000000004000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000004000  R      4000
  LOAD           0x0000000000004000 0x4000000000000000 0x0000000000000000
                 0x0000000000000000 0x00000000000c8000  R E    4000
  LOAD           0x0000000000004000 0x6000000000004000 0x0000000000000000
                 0x000000000000c000 0x000000000000c000  RW     4000
  LOAD           0x0000000000010000 0x6000000000010000 0x0000000000000000
                 0x0000000000004000 0x0000000000004000  RW     4000
  LOAD           0x0000000000014000 0x60000fff7fffc000 0x0000000000000000
                 0x0000000000004000 0x0000000000004000  RW     4000
  LOAD           0x0000000000018000 0x60000fffffff8000 0x0000000000000000
                 0x0000000000004000 0x0000000000004000  RW     4000
  LOAD           0x000000000001c000 0xa000000000020000 0x0000000000000000
                 0x0000000000004380 0x0000000000004380  R      10000
  DYNAMIC        0x000000000001c510 0xa000000000020510 0x0000000000000000
                 0x0000000000000140 0x0000000000000140  R      8
  IA_64_UNWIND   0x000000000001c4c8 0xa0000000000204c8 0x0000000000000000
                 0x0000000000000048 0x0000000000000048  R      8

Dynamic segment at offset 0x1c510 contains 15 entries:
  Tag        Type                         Name/Value
 0x000000000000000e (SONAME)             0x47
 0x0000000000000004 (HASH)               0xa0000000000200e8
 0x0000000000000005 (STRTAB)             0xa000000000020330
 0x0000000000000006 (SYMTAB)             0xa000000000020180
 0x000000000000000a (STRSZ)              97 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000070000000 (IA_64_PLT_RESERVE)  0x0 -- 0x18
 0x0000000000000003 (PLTGOT)             0x0
 0x0000000000000007 (RELA)               0x0
 0x0000000000000008 (RELASZ)             0 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffc (VERDEF)              0x000000006ffffffd (VERDEFNUM)          2
 0x000000006ffffff0 (VERSYM)              0x0000000000000000 (NULL)               0x0

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

Notes at offset 0x00000270 with length 0x00001c20:
  Owner		Data size	Description
  CORE		0x00000478	NT_PRSTATUS (prstatus structure)
  CORE		0x00000088	NT_PRPSINFO (prpsinfo structure)
  CORE		0x00000ed0	NT_TASKSTRUCT (task structure)
  CORE		0x00000800	NT_FPREGSET (floating point registers)

Even though it reports that seeks to small addresses failed, in fact what
it's doing is trying to seek to bad file offsets::

$ strace ./readelf -a /nue/tmp/core 2>&1 | fgrep lseek|fgrep "= -1"
lseek(3, 11529215046068617216, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 11529215046068617216, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 11529215046068617216, SEEK_SET) = -1 EINVAL (Invalid argument)

where 11529215046068617216 = 0xa000000000024000.

I suspect what readelf ought to be doing is read the program headers
until it finds a segment that covers the desired virtual address, then
pick up the file offset from the program header.

However, I don't know enough about readelf to know whether this would
impact other things negatively.

Do you think this is something that could be fixed?

Thanks,

	--david

----- End forwarded message -----