From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4834 invoked by alias); 17 Sep 2014 20:10:59 -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 4801 invoked by uid 89); 17 Sep 2014 20:10:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.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; Wed, 17 Sep 2014 20:10:56 +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 s8HKArI8028602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 17 Sep 2014 16:10:53 -0400 Received: from host2.jankratochvil.net (ovpn-116-67.ams2.redhat.com [10.36.116.67]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8HKAnwL028527 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 17 Sep 2014 16:10:52 -0400 Date: Wed, 17 Sep 2014 20:10:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Doug Evans , "gdb-patches@sourceware.org" Subject: Re: time to workaround libc/13097 in fsf gdb? Message-ID: <20140917201049.GA22880@host2.jankratochvil.net> References: <5411CFAE.7040805@redhat.com> <20140912115452.GA5626@host2.jankratochvil.net> <5412E3AC.80203@redhat.com> <20140912123320.GA8704@host2.jankratochvil.net> <5412EB1F.40309@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5412EB1F.40309@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00595.txt.bz2 On Fri, 12 Sep 2014 14:46:23 +0200, Pedro Alves wrote: > On 09/12/2014 01:33 PM, Jan Kratochvil wrote: > > 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. Like, similar to > >> your gdbarch_solib_file_not_found_is_ok patch, but look at the > >> addresses rather than filenames in the hook. I'm not sure > >> whether that'd complicate things too much. > > > > Everything can be done but this is again changing a direction/behavior of GDB > > upon receiving a fix of current behavior. So far GDB has not been including > > vDSO in the library list and the patch was fixing that behavior. One can go > > very far from doing one fix up to rewriting GDB from scratch. > > I think that's a bit uncalled for and unfair -- AIUI, your original patch > even did that; it left vdso.so in the list. > > I had said: > > "Alternatively to hard coding the names, maybe we could match the vdso address > found through that with the addresses found iterating the dynamic linker list, to > know which dynamic linker entry is the vdso." > > And your new patch said: > > "But now it discards any shared libraries which match a symbol file loaded via > add-symbol-file-from-memory. Which may be OK but it is more widespread change > than before." > > I was only clarifying what I had already said in the message > you replied to. Do you mean that "Alternatively to hard coding the names, maybe we could" was only an idea which I should have ignored? I had the title global maintainer that time so I probably should have checked in a patch after a timeout but I always found the timeout rule (if there is any such rule) broken relying on a luck, compared to Gerrit's flagging of patches by multiple maintainers. > I have no idea what problems you found in the original patch that led to > redesigning the patch to filter out instead, As there was the discussion whether the list of names of former patch Message-ID: <20121122201737.GA32172@host2.jankratochvil.net> is complete and whether one should not use the address match instead. The new patch Message-ID: <20121125181505.GA26194@host2.jankratochvil.net> filters-out the vDSO from library list as is done by FSF GDB HEAD. Each of the patches is considered to have some disadvantages, IIUC. But all of them are just theoretical in the usual GDB nitpicking style. > or what you saw that would suggest that doing that change would require > tilting so much in the "rewriting GDB from scratch" direction. For each fix of GDB one has to consider how widespread the fix should be. Any fix present on gdb-patches is wrong as it is not written in an effective/maintainable language (C++/Java/C#/others). Therefore a full fix would be always to rewrite GDB into C++/Java/C#/others first - that I call "rewriting GDB from scratch". But that I consider as a too large task to do for any of the fixes, particularly because is then more effective to rather start extending LLDB instead. So a metric of a best fix does not work. Another possible metric is to make a fix in minimal time/effort/cost so that the user is no longer affected by the specific bug being addressed. This metric I try to follow. You seem to evaluate the patches by some other metric which I cannot guess myself in advance to coding a patch. Jan