From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21784 invoked by alias); 13 Mar 2014 09:52:24 -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 21699 invoked by uid 89); 13 Mar 2014 09:52:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Mar 2014 09:52:23 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2D9qJvQ015312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Mar 2014 05:52:19 -0400 Received: from [10.36.116.48] (ovpn-116-48.ams2.redhat.com [10.36.116.48]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2D9qHr2000973; Thu, 13 Mar 2014 05:52:17 -0400 Subject: Re: vdso handling From: Mark Wielaard To: Alan Modra Cc: Cary Coutant , Doug Evans , "Metzger, Markus T" , "gdb@sourceware.org" , "binutils@sourceware.org" In-Reply-To: <20140313010147.GZ26922@bubble.grove.modra.org> References: <20140312071701.GW26922@bubble.grove.modra.org> <20140313010147.GZ26922@bubble.grove.modra.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 13 Mar 2014 09:52:00 -0000 Message-ID: <1394704336.11818.115.camel@bordewijk.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00129.txt.bz2 On Thu, 2014-03-13 at 11:31 +1030, Alan Modra wrote: > 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. Note that the vdso is often special, compared to other ELF dsos, because the loaded part is just the complete ELF image in memory. Since they are very simple they will just have one PT_LOAD at offset zero and if the image is smaller than the page size then the whole file is just simply mapped into memory completely. So by fetching the vdso ELF image from remote memory you should be able to get the section headers and the not-allocated sections too. Cheers, Mark