From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17511 invoked by alias); 13 Mar 2014 14:38:05 -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 17305 invoked by uid 89); 13 Mar 2014 14:38:04 -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 14:38:02 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2DEbx4g019421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Mar 2014 10:37:59 -0400 Received: from [10.36.116.48] (ovpn-116-48.ams2.redhat.com [10.36.116.48]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s2DEbvXK028928; Thu, 13 Mar 2014 10:37:57 -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: <20140313130322.GA3384@bubble.grove.modra.org> References: <20140312071701.GW26922@bubble.grove.modra.org> <20140313010147.GZ26922@bubble.grove.modra.org> <1394704336.11818.115.camel@bordewijk.wildebeest.org> <20140313130322.GA3384@bubble.grove.modra.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 13 Mar 2014 14:38:00 -0000 Message-ID: <1394721476.11818.128.camel@bordewijk.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-03/txt/msg00034.txt.bz2 On Thu, 2014-03-13 at 23:33 +1030, Alan Modra wrote: > On Thu, Mar 13, 2014 at 10:52:16AM +0100, Mark Wielaard wrote: > > 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. > > Yes, but if the vdso does not fit in a page (which incidentally is > inferred by program header p_align), then you may lose the section > headers. I was assuming this was the case. Yes, you are right. Almost everything else is bigger than a page and has multiple PT_LOAD segments. In which case determining whether the full shdrs were mapped in from the file is much trickier. And might have to rely on only the phdrs. We recently went through this for elfutils, which also contains an elf_from_remote_memory implementation (if someone needs inspiration). Currently that implementation just uses the phdrs and so needs some heuristics using the program header fields to know what part of the file was mapped where. But if you have access to the actual /proc/PID/maps ranges you might be able to do something more accurate, or at least be able to cross check that the program headers view is really how the ELF image is actually laid out (*). Cheers, Mark (*) Don't make the mistake we made to think p_align is what segments are actually aligned to, the dynamic loader on GNU/Linux just uses the actual page size of the architecture to align the mappings: https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-March/003859.html