Movatterモバイル変換
[0]ホーム
This is the mail archive of thebinutils@sources.redhat.commailing list for thebinutils 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 allabout the slightly odd format of current Linux's ELF core files. Therecent change that seems to confuse readelf is that a core file has somenew phdrs other than PT_NOTE and PT_LOAD. It has a PT_DYNAMIC pointing tothe .dynamic section of the kernel-supplied DSO image in the dead process'saddress space. Similarly there is a PT_IA_64_UNWIND (on ia64) orPT_GNU_EH_FRAME (on x86, maybe later others too). The p_vaddr fieldscorrectly identify the user addresses where these things were found in thelive process. Unless there is a bug, the p_offset fields correctlyidentify where they were stored in the core file. It seems to me readelfmust 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:> OwnerData sizeDescription> CORE0x00000478NT_PRSTATUS (prstatus structure)> CORE0x00000088NT_PRPSINFO (prpsinfo structure)> CORE0x00000ed0NT_TASKSTRUCT (task structure)> CORE0x00000800NT_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 -----
[8]ページ先頭