From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32247 invoked by alias); 13 Mar 2014 10:46:52 -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 32228 invoked by uid 89); 13 Mar 2014 10:46:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 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 10:46:50 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2DAkkm6014628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Mar 2014 06:46:46 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2DAkgvU001027; Thu, 13 Mar 2014 06:46:44 -0400 Message-ID: <53218C92.9050303@redhat.com> Date: Thu, 13 Mar 2014 10:46:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Metzger, Markus T" CC: Alan Modra , Cary Coutant , Doug Evans , "gdb@sourceware.org" , "binutils@sourceware.org" Subject: Re: vdso handling References: <20140312071701.GW26922@bubble.grove.modra.org> <20140313010147.GZ26922@bubble.grove.modra.org> <5321834E.9000509@redhat.com> In-Reply-To: <5321834E.9000509@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-03/txt/msg00031.txt.bz2 On 03/13/2014 10:07 AM, Pedro Alves wrote: > Why's that? Why doesn't the memory-backed bfd paths take the same paths as > a file-backed bfd internally in bfd? It sounds to me that this should be > doable without duplication. BTW, I meant that for vDSO's only. The vsyscall page is not an elf, and therefore bfd still needs to be passed a template elf. For the latter, GDB would indeed need to work with the segments. Do we still care for vsyscall kernels? But for the former, bfd should just be able to read the whole DSO as a plain elf. Some glibc versions even include the vdso in the DSO list (*), and GDB should be able to tell that that DSO is the vDSO (by matching addresses), and load it completely from memory, still using a memory backed bfd, but _without_ a template. So with that in mind, bfd should be able to read the vdso as a bfd from memory using the same paths as a file-backed bfd, except, well, the bfd's backing store is in memory rather than in a file. (*) note how linux-vdso.so.1 is listed by ldd, even if "info shared" in gdb doesn't show it, on some systems. -- Pedro Alves