From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2046 invoked by alias); 1 Jun 2014 20:32:46 -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 2029 invoked by uid 89); 1 Jun 2014 20:32:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sun, 01 Jun 2014 20:32:41 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WrCQm-0007FX-Vb for gdb@sourceware.org; Sun, 01 Jun 2014 22:32:36 +0200 Received: from 207-172-123-137.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com ([207.172.123.137]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jun 2014 22:32:36 +0200 Received: from naesten by 207-172-123-137.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jun 2014 22:32:36 +0200 To: gdb@sourceware.org From: Samuel Bronson Subject: Re: vdso handling Date: Sun, 01 Jun 2014 20:32:00 -0000 Message-ID: <87a99w2wxw.fsf@naesten.mooo.com> References: <20140312071701.GW26922@bubble.grove.modra.org> <20140313010147.GZ26922@bubble.grove.modra.org> <5321834E.9000509@redhat.com> <53218C92.9050303@redhat.com> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cc: binutils@sourceware.org X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00001.txt.bz2 Pedro Alves writes: > 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 ^^^^^^^^^^^^^^^^^^^^^ Hmm, why don't we already do that? It's bound to be easier than meeting the conditions to get glibc to stop falsely cliaming that the vDSO comes from a file . That'd be enough to take two bugs off of right there. > 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. What versions don't list the vdso under some name or other? (Mine calls it linux-gate.so.1 for some reason.) -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!