This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
[davidm@napali.hpl.hp.com: readelf question]
- From: "H. J. Lu" <hjl at lucon dot org>
- To: roland at redhat dot com, GDB <gdb at sources dot redhat dot com>, binutils at sources dot redhat dot com
- Date: Fri, 13 Jun 2003 07:55:20 -0700
- Subject: [davidm@napali.hpl.hp.com: readelf question]
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 -----