From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30205 invoked by alias); 23 Sep 2014 12:05:10 -0000 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 Received: (qmail 30175 invoked by uid 89); 23 Sep 2014 12:05:09 -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,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 23 Sep 2014 12:05:08 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8NC55Du018312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 23 Sep 2014 08:05:06 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8NC54UK012069; Tue, 23 Sep 2014 08:05:04 -0400 Message-ID: <542161EF.7020108@redhat.com> Date: Tue, 23 Sep 2014 12:05:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Jan Kratochvil CC: Doug Evans , "gdb-patches@sourceware.org" Subject: Re: time to workaround libc/13097 in fsf gdb? References: <20140922183505.GA21660@host2.jankratochvil.net> In-Reply-To: <20140922183505.GA21660@host2.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00679.txt.bz2 On 09/22/2014 07:35 PM, Jan Kratochvil wrote: > Clarifying it does not fulfill this your suggestion: > > On Fri, 12 Sep 2014 14:14:36 +0200, Pedro Alves wrote: > # I was more inclined to leave the vdso in the shared library list > # though, like ldd does, than filtering it out. > > But I understand it was more a suggestion than requirement for patch acceptance. > IMO it was request for an unrelated feature. I don't think of it as unrelated (your original patch did that even, after all), but also not required for acceptance. An important goal of review and maintenance IMO is checking whether we're taking steps in the right direction. I hadn't identified the issues with solib-svr4.c vs symfile-mem.c and DSO lifetimes at that point. As I said, I've investigated this further now. I now believe that we're still a couple steps away from being able to list the vdso without causing other issues. In the patch'es commit log, I wrote: "It would actually be nice if GDB also listed the vdso in the shared library list, but there are some design considerations with that: - the vDSO is mapped by the kernel, not userspace, therefore we should load its symbols right from the process's start of life, even before glibc / the userspace loader sets up the initial DSO list. The program might even be using a custom loader or no loader. - that kind of hints at that solib.c should handle retrieving shared library lists from more than one source, and that symfile-mem.c's loading of the vdso would be converted to load and relocate the vdso's bfd behind the target_so_ops interface. - and then, once glibc links in the vdso to its DSO list, we'd need to either: a) somehow hand over the vdso from one target_so_ops to the other b) or simply keep hiding glibc's entry. And then b) seems the simplest." IOW, I'm now convinced that making solib-svr4.c hide the vDSO is _not_ a step backwards from making "info shared" list the vDSO. I didn't like much the way the address matching was done though, hence the new patch revision. Thanks, Pedro Alves