From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4571 invoked by alias); 26 Mar 2014 09:32:32 -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 4544 invoked by uid 89); 26 Mar 2014 09:32:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS 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; Wed, 26 Mar 2014 09:32:29 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 26 Mar 2014 02:32:17 -0700 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga002.jf.intel.com with ESMTP; 26 Mar 2014 02:32:16 -0700 Received: from irsmsx151.ger.corp.intel.com (163.33.192.59) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Mar 2014 09:32:14 +0000 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.2]) by IRSMSX151.ger.corp.intel.com ([163.33.192.59]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 09:32:14 +0000 From: "Metzger, Markus T" To: Pedro Alves , Alan Modra CC: Mark Wielaard , Cary Coutant , "Doug Evans" , "gdb@sourceware.org" , "binutils@sourceware.org" Subject: RE: vdso handling Date: Wed, 26 Mar 2014 09:32: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> <20140320015950.GB13347@bubble.grove.modra.org> <532C60CA.6090008@redhat.com> In-Reply-To: <532C60CA.6090008@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-03/txt/msg00266.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Friday, March 21, 2014 4:55 PM > >> If we can't trust the image to contain everything that the ELF header > >> describes, would it be safer to generate fake sections based on the > >> program header? We already assume that the program header is > >> contained in the image. > > > > Yes, you're correct that it is wrong to assume program headers are > > loaded. Even worse, the in-memory image doesn't even need to contain > > the ELF file header. >=20 > Yeah, and I was just assuming it didn't, hence my "just trust the > headers" push before. >=20 > I'm now thinking that we'll need pseudo-sections from program > headers anyway, so I'd suggest going in that direction, leaving > the add-symbol-file-from-memory command's intention generic, > and leave revisiting how gdb retrieves the vdso itself off of > memory for another day. That would be something like the patch in one of the previous emails in this thread: https://sourceware.org/ml/gdb/2014-03/msg00028.html, wouldn't it? Alan, would you be OK with this, as well? 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