From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9502 invoked by alias); 12 Mar 2014 11:31:08 -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 9472 invoked by uid 89); 12 Mar 2014 11:31:05 -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,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 12 Mar 2014 11:31:04 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 5421433F926; Wed, 12 Mar 2014 11:31:02 +0000 (UTC) From: Mike Frysinger To: gdb@sourceware.org Cc: Alan Modra , "Metzger, Markus T" , "binutils@sourceware.org" Subject: Re: vdso handling Date: Wed, 12 Mar 2014 11:31:00 -0000 Message-ID: <1676801.XSU6BsarlE@vapier> User-Agent: KMail/4.12.3 (Linux/3.13.0; KDE/4.12.3; x86_64; ; ) In-Reply-To: <20140312071701.GW26922@bubble.grove.modra.org> References: <20140312071701.GW26922@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2688228.YcrkvNIgGp"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00017.txt.bz2 --nextPart2688228.YcrkvNIgGp Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Content-length: 1398 On Wed 12 Mar 2014 17:47:02 Alan Modra wrote: > On Mon, Mar 10, 2014 at 01:04:33PM +0000, Metzger, Markus T wrote: > > I noticed that the BFD created for the VDSO (system-provided in-memory > > DSO) does not contain any BFD sections. Is this intentional? Or has > > there just been no need for them? >=20 > [snip] >=20 > > The vdso is processed in symbol_file_add_from_memory at > > gdb/symfile-mem.c:84. It calls bfd_from_remote_memory to create a BFD > > for the vdso and then processes it. >=20 > The underlying cause is that you're trying to debug an ELF binary that > only contains the execution view. The linking view (of which the > sections are a part) is not loaded, so bfd_from_remote_memory does not > have this information. See elfcode.h bfd_from_remote_memory. >=20 > You can see similar breakage of gdb and binutils if you zap e_shoff, > e_shnum, and e_shstrndx of your favourite hello world program. >=20 > I suppose one way to provide something that gdb and other tools expect > would be to treat the vdso like a core file, and create fake sections > corresponding to the program headers. I'm not really keen on the idea > though, since I know that will open up a can of worms. >=20 > Can't you point gdb at a file image for the vdso? i don't think distros generally ship it ? the kernel doesn't install it by= =20 default (e.g. into /lib/modules/$(uname -r)/vdso/). -mike= --nextPart2688228.YcrkvNIgGp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABAgAGBQJTIEV3AAoJEEFjO5/oN/WBHokP/i529focy60MXKHIeNIJJMMF SYzyQDLxfzQJt8JYcz/ZdHvkQY8lvKUOA52PcQpD3OnTET4iulN4YBwGcMtjYI89 9Ey0MYhnNXg8zf0SZqvDK9NzTu7ErJkDyPCSp+Y2S7y8iKvDBmw/UBZ9OKaSX52X wKqI1pML02DvscFcG32n8gf0PEbnz5y6mEKTA0JKwVEO+FJTcvYpsB1ikievOIqQ YeJXOP7FcPLIyce94JgEWKp+7WnZpvCRDkcW8jXxqzT4h9VIfU7s1HbhWg8kQzn8 dyzLMGFcqEcFMGqzNTxkNYqdS2iqnJF5/d3b6GXMmeOV9EnnAjVHN5vudtQjgTkZ hb80VuTsn+piDK602MyrvolZiylWTt7f4sjbElyMnGXlpibJIMmx4ryKLNDNtlgQ B+bPRa99P0IHZfyd3AXUJq5RuZjeztnkMwh2L8PGYA5QGxtuAa2aG9hGvJjs2BIy rfOEN/8yA7KQHMWccr1VBGF46rXJvFJZIFBtnS1Ysl8UtCUA2Y1VFOSPeJu5OnTS W8jyxQnKmSBPH8H7iz1s1wRKPezEamFjceheCPxGPUXY91UpUk9NBJdbrLTNv8wo zlayTdgxIuMdib6bUs94IQ6yCKA7peE4THgwYOOZvG86hmYTdJzfVPQoRYBEEISS UOdWVWTyWeHmx+JWg2Jm =OT3f -----END PGP SIGNATURE----- --nextPart2688228.YcrkvNIgGp--