From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23920 invoked by alias); 28 Nov 2012 01:12:30 -0000 Received: (qmail 23912 invoked by uid 22791); 28 Nov 2012 01:12:29 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Nov 2012 01:12:21 +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 qAS1CFLh005386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 20:12:17 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAS0KFnC016313; Tue, 27 Nov 2012 19:20:16 -0500 Message-ID: <50B558BF.5040300@redhat.com> Date: Wed, 28 Nov 2012 01:12:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mike Frysinger CC: gdb-patches@sourceware.org, Jan Kratochvil Subject: Re: [patch+7.5.1] Work around PR libc/13097 "linux-vdso.so.1" #3 References: <20121122201737.GA32172@host2.jankratochvil.net> <20121123123952.GA15371@host2.jankratochvil.net> <50AF9DBF.1090406@redhat.com> <201211271659.11975.vapier@gentoo.org> In-Reply-To: <201211271659.11975.vapier@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00788.txt.bz2 On 11/27/2012 09:59 PM, Mike Frysinger wrote: > On Friday 23 November 2012 11:01:03 Pedro Alves wrote: >> On 11/23/2012 12:39 PM, Jan Kratochvil wrote: >>> Besides that there is no standard for any such rule and I consider this >>> patch only as a workaround of a WONTFIXed glibc PR. >> >> Given the new order of glibc maintenance, if we believe glibc's WONTFIX was >> wrong, then we should reopen the PR, and retry discussing the issue. > > i think the glibc behavior is actually nice and we don't want to revert it. > if i'm single stepping through code that enters the vdso, if gdb doesn't know > about it, it looks like i just stepped off into the weeds and the program is > doing something wrong. if, instead, it told me i was in the vdso (and we had > some way of communicating symbol information), that's a lot more useful. Indeed. GDB already loads the vDSO 's elf (symfile-mem.c). GDB finds the vdso address in the auxv. I think in Fedora, the idea is to find the debug info file through build id matching (I haven't checked if that's actually implemented, but in previous online searches I found references to that). In I mentioned that this change could make it possible to find the separate debug file by name. I think it'd be nice to turn things around, and list the vDSO in the shared libraries list instead of hiding it. BTW, before that change, when the vDSO was nameless, what made sure it didn't appear in the DSO list? Where was it skipped? -- Pedro Alves