This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [davidm@napali.hpl.hp.com: readelf question]
- From: Roland McGrath <roland at redhat dot com>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: GDB <gdb at sources dot redhat dot com>, binutils at sources dot redhat dot com
- Date: Tue, 17 Jun 2003 13:25:56 -0700
- Subject: Re: [davidm@napali.hpl.hp.com: readelf question]
> Roland, do you know anything about this?
I don't know off hand what precisely is readelf's confusion. I do know all
about the slightly odd format of current Linux's ELF core files. The
recent change that seems to confuse readelf is that a core file has some
new phdrs other than PT_NOTE and PT_LOAD. It has a PT_DYNAMIC pointing to
the .dynamic section of the kernel-supplied DSO image in the dead process's
address space. Similarly there is a PT_IA_64_UNWIND (on ia64) or
PT_GNU_EH_FRAME (on x86, maybe later others too). The p_vaddr fields
correctly identify the user addresses where these things were found in the
live process. Unless there is a bug, the p_offset fields correctly
identify where they were stored in the core file. It seems to me readelf
must have a bug in its interpretation of the headers. I can take a look.
Roland
> 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 -----