From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23201 invoked by alias); 19 Jun 2009 15:00:03 -0000 Received: (qmail 23037 invoked by uid 22791); 19 Jun 2009 15:00:01 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Jun 2009 14:59:58 +0000 Received: (qmail 18565 invoked from network); 19 Jun 2009 14:59:56 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Jun 2009 14:59:56 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] solib-svr4.c - allow reading linkmap info from core without executable Date: Fri, 19 Jun 2009 15:00:00 -0000 User-Agent: KMail/1.9.10 Cc: Mark Kettenis , aristovski@qnx.com References: <200906191442.n5JEg4QW029005@brahms.sibelius.xs4all.nl> In-Reply-To: <200906191442.n5JEg4QW029005@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906191600.43923.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00505.txt.bz2 On Friday 19 June 2009 15:42:04, Mark Kettenis wrote: > > From: Aleksandar Ristovski > > Date: =A0Fri, 19 Jun 2009 10:16:26 -0400 > >=20 > > Pedro Alves wrote: > > >=20 > > > I was thinking on pushing the elf check a bit down instead, > > > like the below. =A0However, having now tested this, I see that > > > this doesn't work in most of the cores I have here (x86_64-linux). > > > In most cases I see, the segment that would contain the program > > > headers, as indicated by auxv info, isn't included in the > > > core... > > >=20 > > > (objdump -h) > > > Idx Name =A0 =A0 =A0 =A0 =A0Size =A0 =A0 =A0VMA =A0 =A0 =A0 =A0 =A0 = =A0 =A0 LMA =A0 =A0 =A0 =A0 =A0 =A0 =A0 File off =A0Algn > > > =A0 : > > > =A0 6 load1 =A0 =A0 =A0 =A0 00000000 =A00000000000400000 =A0000000000= 0000000 =A0000008f8 =A02**0 > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ALLOC, READONLY, CODE > > > =A0 : > > >=20 >=20 > I'm somewhat amazed that the Linux kernel doesn't dump the auxv stuff. > Without the auxv data, debugging core dumps of PIE executables will be > impossible. >=20 > Perhaps the kernel does include the information in the does, but bfd > doesn't have the necessary code to turn it into an .auxv section? Nope, let me explain a bit better: the auxv data is there, but the program headers aren't. Idx Name Size VMA LMA File off A= lgn 0 note0 00000538 0000000000000000 0000000000000000 000003c0 2= **0 CONTENTS, READONLY 1 .reg/30270 000000d8 0000000000000000 0000000000000000 000004e0 2= **2 CONTENTS 2 .reg 000000d8 0000000000000000 0000000000000000 000004e0 2= **2 CONTENTS 3 .reg2/30270 00000200 0000000000000000 0000000000000000 000005d4 2= **2 CONTENTS 4 .reg2 00000200 0000000000000000 0000000000000000 000005d4 2= **2 CONTENTS 5 .auxv 00000110 0000000000000000 0000000000000000 000007e8 2= **3 CONTENTS 6 load1 00000000 0000000000400000 0000000000000000 000008f8 2= **0 ^^^^^^^^ ALLOC, READONLY, CODE ^^^^^^^^^^^^^^^^^^^^^ 7 load2 00001000 0000000000600000 0000000000000000 000008f8 2= **0 CONTENTS, ALLOC, LOAD : In this case, AT_PHDR points at 0x400040, but the data is just not there in the core, because it is read-only data, and the kernel decided it isn't worth to dump it (gdb's gcore does the same): >cat /proc/18439/maps 00400000-00401000 r-xp 00000000 08:07 2819992 /h= ome/pedro/gdb/mainline/build/gdb/testsuite/gdb.base/annota1 ^^^^ 00600000-00601000 rw-p 00000000 08:07 2819992 /h= ome/pedro/gdb/mainline/build/gdb/testsuite/gdb.base/annota1 Aleksandar, did you try the version of the patch I posted? --=20 Pedro Alves