From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18242 invoked by alias); 10 Mar 2014 14:27:45 -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 18173 invoked by uid 89); 10 Mar 2014 14:27:44 -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,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD 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, 10 Mar 2014 14:27:42 +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 s2AEQm0w001969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Mar 2014 10:26:48 -0400 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 s2AEQjUZ031329; Mon, 10 Mar 2014 10:26:46 -0400 Message-ID: <531DCBA5.8010608@redhat.com> Date: Mon, 10 Mar 2014 14: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 , Joel Brobecker Subject: Re: [patchv3 0/8] Validate binary before use References: <20140227213229.GA21121@host2.jankratochvil.net> <5310933E.8000601@redhat.com> <20140302183659.GA11910@host2.jankratochvil.net> <53148332.7010600@redhat.com> <20140308173316.GA18331@host2.jankratochvil.net> In-Reply-To: <20140308173316.GA18331@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-03/txt/msg00241.txt.bz2 On 03/08/2014 05:33 PM, Jan Kratochvil wrote: > On Mon, 03 Mar 2014 14:27:14 +0100, Pedro Alves wrote: >> On 03/02/2014 06:36 PM, Jan Kratochvil wrote: >>>> 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. > > Yes, may extensions would be useful. > The question is if it should be a blocker for this patch series. Not at all, IMO. I was just really asking whether that was already in the works. If not, fine, it's still forward progress without it. >> 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. > > Created: > https://sourceware.org/gdb/wiki/GDBserverCoreFiles > And removed it from: > https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity?action=diff&rev2=57&rev1=56 Thanks. > > >> #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? > > I did not think more about it as I have never started that project. > > The basic functionality would be: > $ gdbserver -c :1234 corefile > $ gdb executable > (gdb) target remote :1234 > And if I did not forget anything it could work. Yeah. I was more thinking of (persistent) extended-remote, like: $ gdbserver --multi :1234 $ gdb (gdb) target extended-remote :1234 (gdb) ??? Just "core COREFILE" at that point currently makes GDB disconnect from the remote, and load the core itself (on the host). Ideally we'd have some way to tell GDB we actually want to load the core on the currently connected remote end. I guess a new knob ('set core host/target/auto'), plus a new option to the "core" command, like "core -target" or some such. Seems doable. -- Pedro Alves