From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11502 invoked by alias); 13 Mar 2014 09:48:00 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 11483 invoked by uid 89); 13 Mar 2014 09:47:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Mar 2014 09:47:58 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 13 Mar 2014 02:43:26 -0700 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga001.fm.intel.com with ESMTP; 13 Mar 2014 02:47:46 -0700 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 13 Mar 2014 09:47:44 +0000 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.27]) by IRSMSX152.ger.corp.intel.com ([169.254.6.180]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 09:47:44 +0000 From: "Metzger, Markus T" To: Alan Modra , Cary Coutant CC: Doug Evans , "gdb@sourceware.org" , "binutils@sourceware.org" Subject: RE: vdso handling Date: Thu, 13 Mar 2014 09:48:00 -0000 Message-ID: References: <20140312071701.GW26922@bubble.grove.modra.org> <20140313010147.GZ26922@bubble.grove.modra.org> In-Reply-To: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-03/txt/msg00128.txt.bz2 > -----Original Message----- > From: Metzger, Markus T > Sent: Thursday, March 13, 2014 9:24 AM > > On Wed, Mar 12, 2014 at 01:22:58PM -0700, Cary Coutant wrote: > > > > I think a case can be made that gdb should be able to use the > > > > "execution view" of the program here. > > > > As for how to achieve that ... "Discuss." :-) > > > > > > Add a PT_DEBUG program header entry? The PT_DEBUG segment would > > need > > > to have a small header that allows the debugger to find .debug_abbrev, > > > .debug_info, etc. (i.e., a mini section table). Or, just add > > > individual program header entries for each of the standard debug > > > sections: PT_DEBUG_ABBREV, PT_DEBUG_INFO, etc. > > > > Debug sections are not normally loaded. For that reason I don't think > > it makes any sense to specify program headers for them. It wouldn't > > help in the vdso case anyway, since the problem there is that you only > > have the loaded part of the original ELF file. >=20 > The vdso contains a section table, as well. When I hack > bfd_from_remote_memory to create BFD sections from them similar > to what elf_object_p does, I get the target sections that I wanted in GDB. > The patch is rather big, though, and duplicating a lot of elf_object_p's = code. >=20 > I have not tried generating fake sections from segments, yet. This turned out to be rather simple. Is this the right direction to go? Should I maybe restrict this to PT_LOAD segments? diff --git a/bfd/elfcode.h b/bfd/elfcode.h index 20101be..22aae2a 100644 --- a/bfd/elfcode.h +++ b/bfd/elfcode.h @@ -1771,7 +1771,6 @@ NAME(_bfd_elf,bfd_from_remote_memory) return NULL; } } - free (x_phdrs); =20 /* If the segments visible in memory didn't include the section headers, then clear them from the file header. */ @@ -1791,6 +1790,7 @@ NAME(_bfd_elf,bfd_from_remote_memory) bim =3D (struct bfd_in_memory *) bfd_malloc (sizeof (struct bfd_in_memor= y)); if (bim =3D=3D NULL) { + free (x_phdrs); free (contents); bfd_set_error (bfd_error_no_memory); return NULL; @@ -1799,6 +1799,7 @@ NAME(_bfd_elf,bfd_from_remote_memory) if (nbfd =3D=3D NULL) { free (bim); + free (x_phdrs); free (contents); bfd_set_error (bfd_error_no_memory); return NULL; @@ -1815,6 +1816,12 @@ NAME(_bfd_elf,bfd_from_remote_memory) nbfd->mtime =3D time (NULL); nbfd->mtime_set =3D TRUE; =20 + /* Add fake sections for program headers. We ignore errors. */ + for (i =3D 0; i < i_ehdr.e_phnum; ++i) + (void) bfd_section_from_phdr (nbfd, &i_phdrs[i], i); + + free (x_phdrs); + if (loadbasep) *loadbasep =3D loadbase; return nbfd; regards, markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052