From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10502 invoked by alias); 17 Jun 2003 20:26:00 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10435 invoked from network); 17 Jun 2003 20:25:58 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 17 Jun 2003 20:25:58 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 9AC75354C; Tue, 17 Jun 2003 13:25:57 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h5HKPu628945; Tue, 17 Jun 2003 13:25:56 -0700 Date: Tue, 17 Jun 2003 20:26:00 -0000 Message-Id: <200306172025.h5HKPu628945@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: "H. J. Lu" Cc: GDB , binutils@sources.redhat.com Subject: Re: [davidm@napali.hpl.hp.com: readelf question] In-Reply-To: H. J. Lu's message of Friday, 13 June 2003 07:55:20 -0700 <20030613145520.GA2930@lucon.org> X-Zippy-Says: Hey, I LIKE that POINT!! X-SW-Source: 2003-06/txt/msg00352.txt.bz2 > 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 ----- > > Delivered-To: hjl@localhost.lucon.org > From: David Mosberger > Date: Fri, 13 Jun 2003 00:00:39 -0700 > To: "H. J. Lu" > 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 -----