From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34674 invoked by alias); 5 May 2015 20:45: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 34659 invoked by uid 89); 5 May 2015 20:45:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailrelay114.isp.belgacom.be Received: from mailrelay114.isp.belgacom.be (HELO mailrelay114.isp.belgacom.be) (195.238.20.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 May 2015 20:45:42 +0000 X-Belgacom-Dynamic: yes X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=b5VF44rymZs9Y1DiFqPAMix8rWtyBsB+bu/OWkEeo3k= c=1 sm=2 a=IkcTkHD0fZMA:10 a=0u0F2W6eY_qk5IFp4fkA:9 a=QEXdDO2ut3YA:10 a=EytTJD00wsZKrx9n:21 a=Ji9ge-Swshko8CY2:21 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CVAQBvK0lV/7LMgG0NT4dYx26CXgKBehEBAQEBAQEBhSsBAQQjVhALDgoCAiYCAlcGiESwMXCTXgEBAQEBAQEBAQEBAQEBAR2BIYoYhQUHgmiBRQWGVJdDhkuKbYNTgiocgVODMgEBAQ Received: from 178.204-128-109.adsl-dyn.isp.belgacom.be (HELO [192.168.1.14]) ([109.128.204.178]) by relay.skynet.be with ESMTP; 05 May 2015 22:45:39 +0200 Subject: Re: qXfer:exec-file:read and non multiprocess target From: Philippe Waroquiers To: Gary Benson Cc: gdb-patches@sourceware.org In-Reply-To: <20150505110207.GA17684@blade.nx> References: <1430560118.11263.9.camel@soleil> <20150505110207.GA17684@blade.nx> Content-Type: text/plain; charset="UTF-8" Date: Tue, 05 May 2015 20:45:00 -0000 Message-ID: <1430858744.2174.5.camel@soleil> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00085.txt.bz2 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] ... and then GDB could properly use the returned exec-file (even if vFile is not supported by Valgrind gdbserver). Thanks Philippe