From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29601 invoked by alias); 3 Mar 2014 13:27:30 -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 29590 invoked by uid 89); 3 Mar 2014 13:27:30 -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; Mon, 03 Mar 2014 13:27:28 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s23DRH5L031162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Mar 2014 08:27:18 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s23DREpl021668; Mon, 3 Mar 2014 08:27:15 -0500 Message-ID: <53148332.7010600@redhat.com> Date: Mon, 03 Mar 2014 13:27: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> <5310933E.8000601@redhat.com> <20140302183659.GA11910@host2.jankratochvil.net> In-Reply-To: <20140302183659.GA11910@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-03/txt/msg00033.txt.bz2 On 03/02/2014 06:36 PM, Jan Kratochvil wrote: as it partially overlaps my non-upstreamed "locate > files by their build-id from a core file": > http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-6.6-buildid-locate.patch > > >> BTW, do you plan on contributing support for validation with cores too? > > No. OK. I think it'd be useful, so that GDB can warn/reject in the common scenario of the user not pointing at a sysroot with the correct DSOs. If related I find right to extend gdbserver to support cores, it would be > useful for ABRT to prevent needless uploads of many MBs of compressed core > files. I have added "core file loading " to: > https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity?action=diff&rev2=56&rev1=55 Thanks. I think that feature may be a little beyond borderline for that project page though, as core loading is not really part of the native target. IMO it'd good if this had its own project page, where it'd give answer to questions like the below. #0 - If implemented by gdbserver, it seems like it'd involve further user action to trigger the feature? How does one tell GDB/gdbserver to load the ore on the remote side rather than locally? #1 - couldn't this be addressed by just using fuse/ssh/somesuch to access the core? (that is, transparently from GDB). #2 - if not, could we perhaps tweak the target stratum bits a little to allow sitting core_ops on top of extended-remote, and have it read the necessary bits off the remote core with target_fileio_xxx. So we'd still have host-side core_ops / bfd. You'd load the core with e.g., "core remote:/.../core.pid"). >>> --- 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. > > Why? It counts since the first post to gdb-patches? https://sourceware.org/ml/gdb-patches/2014-02/msg00859.html -- Pedro Alves