From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13803 invoked by alias); 28 Feb 2014 13:47:32 -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 13791 invoked by uid 89); 28 Feb 2014 13:47:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_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 ESMTP; Fri, 28 Feb 2014 13:47:29 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1SDkeQv028327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Feb 2014 08:46:40 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1SDkc5w023889; Fri, 28 Feb 2014 08:46:39 -0500 Message-ID: <5310933E.8000601@redhat.com> Date: Fri, 28 Feb 2014 13:47:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jan Kratochvil CC: gdb-patches@sourceware.org, Aleksandar Ristovski Subject: Re: [patchv3 0/8] Validate binary before use References: <20140227213229.GA21121@host2.jankratochvil.net> In-Reply-To: <20140227213229.GA21121@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00863.txt.bz2 On 02/27/2014 09:32 PM, Jan Kratochvil wrote: > Hi, > > git://sourceware.org/git/archer.git > jankratochvil/gdbserverbuildid > - although it is not properly separated into 1..8 there as in this series Thanks. Personally for review, I prefer a git branch with the exact same contents as posted. (BTW, git am caught a couple whitespace issues: $ git am /tmp/jan1 Applying: Move utility functions to common/ Applying: Merge multiple hex conversions Applying: Create empty common/linux-maps.[ch] and common/common-target.[ch] Applying: Prepare linux_find_memory_regions_full & co. for move Applying: Move linux_find_memory_regions_full & co. Applying: gdbserver build-id attribute generator Applying: Validate symbol file using build-id Applying: Tests for validate symbol file using build-id /home/pedro/gdb/mygit/src/.git/rebase-apply/patch:256: trailing whitespace. /home/pedro/gdb/mygit/src/.git/rebase-apply/patch:271: trailing whitespace. # Keep previous so for debugging puroses /home/pedro/gdb/mygit/src/.git/rebase-apply/patch:274: trailing whitespace. # Copy loaded so over the one gdb will find warning: 3 lines add whitespace errors.) I looked through the whole series, and sent out a few minor comments, but it all looked good to me otherwise. I think this is a quite nice feature. Thanks for doing this (you both). > > the is a follow-up to never checked in series: > Message-ID: <1366127096-5744-1-git-send-email-ARistovski@qnx.com> > https://sourceware.org/ml/gdb-patches/2013-04/msg00472.html To save others the same, I followed a few links to find the description of the series, here: https://sourceware.org/ml/gdb-patches/2013-04/msg00220.html > Implementing new feature into gdbserver and not linux-nat seems correct to > me according to: > https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity > I will list there this local/remote difference after check-in but that > should be OK after the final switch to gdbserver. If only one side can be implemented, then yes, agreed, let's prefer the GDBserver side. However, if not hard, I'd rather we did both, as we can't tell how long it will take until we finally share the backends. It's only the case of only implementing something _only_ on the native side and not in gdbserver that puts us further away from the end goal. With that in mind, how hard would it be to support this on current native as well? Can we do it by sharing most of the build id code, say by splitting out most of the Linux build id stuff out a linux-buildid.c file that is built by both gdb and gdbserver? BTW, do you plan on contributing support for validation with cores too? I think this should be mentioned in NEWS. The new attribute of the xml of qXfer:libraries-svr4 should be mentioned in NEWS too. Also, I think somewhere in the manual we should explain this: + warning (_("Shared object \"%s\" could not be validated " + "and will be ignored."), so->so_name); I wonder whether we'll need to let the user force-disable this validation? I think so. Sometimes it might be useful to force GDB into taking the symbols even if it's not an exact match (say, if one rebuilds to get back symbols, or to get around potential tooling problems). > --- a/gdb/testsuite/gdb.base/solib-mismatch.exp> +++ b/gdb/testsuite/gdb.base/solib-mismatch.exp > @@ -1,4 +1,4 @@ > -# Copyright 2013 Free Software Foundation, Inc. > +# Copyright 2014 Free Software Foundation, Inc. These need to be 2013-2014. -- Pedro Alves