From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7029 invoked by alias); 8 Mar 2014 17:33:31 -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 7016 invoked by uid 89); 8 Mar 2014 17:33:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 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; Sat, 08 Mar 2014 17:33:27 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s28HXKKe028366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Mar 2014 12:33:20 -0500 Received: from host2.jankratochvil.net (ovpn-116-86.ams2.redhat.com [10.36.116.86]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s28HXG5N002510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Mar 2014 12:33:19 -0500 Date: Sat, 08 Mar 2014 17:33:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org, Aleksandar Ristovski , Joel Brobecker Subject: Re: [patchv3 0/8] Validate binary before use Message-ID: <20140308173316.GA18331@host2.jankratochvil.net> References: <20140227213229.GA21121@host2.jankratochvil.net> <5310933E.8000601@redhat.com> <20140302183659.GA11910@host2.jankratochvil.net> <53148332.7010600@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53148332.7010600@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00215.txt.bz2 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. > 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 > #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. For more comfortable use it overlaps more with my non-upstreamed patches: http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-6.6-buildid-locate.patch http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-6.6-buildid-locate-core-as-arg.patch So that one could possibly load executable+libraries by: $ gdbserver :1234 corefile $ gdb (gdb) target (extended-?)remote :1234 The same way one can load executable+libraries in linux-nat and the patches above using: $ gdb corefile > #1 - couldn't this be addressed by just using fuse/ssh/somesuch to > access the core? (that is, transparently from GDB). It could but in many cases would be slower than uploading the whole corefile. It all depends on upload bandwidth vs. RTT. Depending on these two link parameters currently for some people is faster to do core file upload, for other people to do NFS-like corefile access. The best choice would be the gdbserver-for-corefile as in such case the major RTT hit is the link_map traversal while gdbserver can send qXfer:libraries-svr4:read. OTOH nowadays there is also NT_FILE but so far GDB does not use it for the shared library list, it may also contain ELF files mmap()ed and not dlopen()ed. > #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"). The same performance problem as #1 above. > >>> --- 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 Do you mean this part? # 1. We start claiming copyright the year the file as committed # to a medium (hard drive), not the year it was published. Does "medium" mean any disk even unrelated to the GDB project? Or does "medium" mean "any medium used for GDB development"? It is not discussed more above, I guess you mean the former but was it really meant that way? (Cced Joel) Thanks, Jan