From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28047 invoked by alias); 6 May 2015 10:31:50 -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 28035 invoked by uid 89); 6 May 2015 10:31:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 06 May 2015 10:31:48 +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 (Postfix) with ESMTPS id D3B2B55; Wed, 6 May 2015 10:31:46 +0000 (UTC) Received: from blade.nx (ovpn-116-21.ams2.redhat.com [10.36.116.21]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t46AVkZt012170; Wed, 6 May 2015 06:31:46 -0400 Received: by blade.nx (Postfix, from userid 1000) id 72646263C93; Wed, 6 May 2015 11:31:45 +0100 (BST) Date: Wed, 06 May 2015 10:31:00 -0000 From: Gary Benson To: Philippe Waroquiers Cc: gdb-patches@sourceware.org Subject: Re: qXfer:exec-file:read and non multiprocess target Message-ID: <20150506103145.GA30896@blade.nx> References: <1430560118.11263.9.camel@soleil> <20150505110207.GA17684@blade.nx> <1430858744.2174.5.camel@soleil> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430858744.2174.5.camel@soleil> X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00091.txt.bz2 Philippe Waroquiers wrote: > On Tue, 2015-05-05 at 12:02 +0100, Gary Benson wrote: > > The PID is fake because vgdb does not support multiprocess > > extensions. I don't like sending a fake/zero PID over the wire, > > but how about I change qXfer:exec-file:read to send a NULL annex > > if the remote does not have multiprocess extensions? Can you make > > your side work with the patch inlined below? If so I'll tidy and > > document it and submit it for review. > > It looks effectively better to not send the fake or 0 pid > (e.g. similar to the qAttached packet). > > The valgrind gdbserver side works ok with the patch to send an empty > annex. This is the resulting exchange, traced at Valgrind side: > ... > --4980:3: gdbsrv getpkt ("qAttached"); [no ack] > --4980:3: gdbsrv putpkt ("$1#31"); [no ack] > --4980:3: gdbsrv getpkt ("qXfer:exec-file:read::0,fff"); [no ack] > --4980:3: gdbsrv putpkt ("$l/home/philippe/valgrind/better_stats/memcheck/tests/trivialleak#2c"); [no ack] > --4980:3: gdbsrv getpkt ("vFile:open:2f686f6d652f7068696c697070652f76616c6772696e642f6265747465725f73746174732f6d656d636865636b2f74657374732f7472697669616c6c65616b,0,0"); [no ack] > --4980:3: gdbsrv putpkt ("$#00"); [no ack] > ... Great, I will get that turned into a proper patch today. > and then GDB could properly use the returned exec-file > (even if vFile is not supported by Valgrind gdbserver). Yes, there is a special workaround just for vgdb ;) Cheers, Gary -- http://gbenson.net/