From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17812 invoked by alias); 21 Mar 2014 08:10:12 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 17792 invoked by uid 89); 21 Mar 2014 08:10:11 -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: mga02.intel.com Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Mar 2014 08:10:09 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 21 Mar 2014 01:10:08 -0700 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga002.jf.intel.com with ESMTP; 21 Mar 2014 01:10:06 -0700 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Mar 2014 08:10:04 +0000 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.224]) by IRSMSX152.ger.corp.intel.com ([169.254.6.180]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 08:10:04 +0000 From: "Metzger, Markus T" To: Alan Modra , Pedro Alves CC: Mark Wielaard , Cary Coutant , "Doug Evans" , "gdb@sourceware.org" , "binutils@sourceware.org" Subject: RE: vdso handling Date: Fri, 21 Mar 2014 08:10:00 -0000 Message-ID: References: <20140313010147.GZ26922@bubble.grove.modra.org> <1394704336.11818.115.camel@bordewijk.wildebeest.org> <20140313130322.GA3384@bubble.grove.modra.org> <5321C7C8.6000707@redhat.com> <5321C8FA.40708@gmail.com> <5321CE1A.20509@redhat.com> <20140313235347.GD3384@bubble.grove.modra.org> <20140318230939.GA9145@bubble.grove.modra.org> <5329879C.6070805@redhat.com> <20140320013305.GA13347@bubble.grove.modra.org> In-Reply-To: <20140320013305.GA13347@bubble.grove.modra.org> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00060.txt.bz2 > -----Original Message----- > From: Alan Modra [mailto:amodra@gmail.com] > Sent: Thursday, March 20, 2014 2:33 AM > On Wed, Mar 19, 2014 at 12:03:40PM +0000, Pedro Alves wrote: > > On 03/18/2014 11:09 PM, Alan Modra wrote: > > > I don't think this is a good idea. If/when bfd_from_remote_memory is > > > used for something other than the linux kernel vdso, we can't assume > > > the section headers are loaded. > > > > I wonder what use cases are these though. It'd be odd to me to > > load the elf headers, but not all that the headers point at. >=20 > Well, no, the section headers are part of the linking view. The ELF > file header points at their *file offset*. Thinking it odd that they > are not loaded is exactly the same as thinking it odd that .comment is > not loaded! >=20 > > Sounds like we should just make that a requirement? >=20 > You indeed could make that a requirement, but it'd mean that object > files loaded by glibc ld.so would not satisfy the requirement. >=20 > Taking Markus' vdso as an example, the PT_LOAD header covers file > offsets from 0 to 0xffd and page size is 0x1000. If ld.so were > loading a similar image, it would just load in 0 to 0xfff (assuming > ld.so's dl_pagesize is also 0x1000). The section headers are at file > offset 0x10e0 so would miss being loaded. Nor should they be loaded, > since they are completely extraneous to executing the image it would > be foolish to waste another page to load them. >=20 > > "This command may not really be worth having, but it serves to exercise > the > > underlying function symbol_file_add_from_memory. That function does > the > > work of reading symbols and unwind info from the Linux vsyscall DSO." >=20 > Heh, OK, so don't let my comments about more general uses of > bfd_from_remote_memory get in your way of fixing this problem. >=20 > Hmm, if you only want to read vdsos then bfd_from_remote_memory is way > overengineered. In fact, I think it could disappear entirely. > If you can find the extent of the vdso in gdb, then all of the ELF > version of bfd_from_remote_memory prior to allocating the bim is > unnecessary, because all that code really does is find the extent. > So the tail of bfd_from_remote_memory moves to bfd/opncls.c as > (totally untested): >=20 > bfd_boolean > bfd_openr_bim (bfd *templ, void *contents, size_t contents_size) > { > struct bfd_in_memory *bim; >=20 > bim =3D (struct bfd_in_memory *) bfd_malloc (sizeof (struct > bfd_in_memory)); > if (bim =3D=3D NULL) > return NULL; >=20 > nbfd =3D _bfd_new_bfd (); > if (nbfd =3D=3D NULL) > { > free (bim); > return NULL; > } > nbfd->filename =3D ""; > if (templ !=3D NULL) > nbfd->xvec =3D templ->xvec; > bim->size =3D contents_size; > bim->buffer =3D (bfd_byte *) contents; > nbfd->iostream =3D bim; > nbfd->flags =3D BFD_IN_MEMORY; > nbfd->iovec =3D &_bfd_memory_iovec; > nbfd->origin =3D 0; > nbfd->direction =3D read_direction; > nbfd->mtime =3D time (NULL); > nbfd->mtime_set =3D TRUE; > return nbfd; > } >=20 > gdb is then responsible for filling in "contents" and determining > "contents_size", which presumably can be done in the same way as > you did in https://sourceware.org/ml/binutils/2014-03/msg00130.html > The loadbase calculation also moves to gdb, which shouldn't be too > hard. Note that "templ" above is optional, which allows you to get > rid of > /* FIXME: cagney/2004-05-06: Should not require an existing > BFD when trying to create a run-time BFD of the VSYSCALL I was waiting for Pedro to reply but he didn't. This would move the ELF processing itself into GDB. That sounds a bit odd to me but it seems GDB already does a fair amount of ELF reading. Pedro, are you OK with this? Will you accept a patch that goes into the direction that Alan described above? Thanks, 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