From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12705 invoked by alias); 10 Dec 2013 21:46:08 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 12687 invoked by uid 89); 10 Dec 2013 21:46:07 -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_50,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailrelay003.isp.belgacom.be Received: from Unknown (HELO mailrelay003.isp.belgacom.be) (195.238.6.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Dec 2013 21:46:06 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBANB8p1JtgOB+/2dsb2JhbAANTIcRth6BN4MZAQEBAwEjVgULCxoCJgICVwaIDwuwUXaPVReBKY1cB4JsgUgErVE Received: from 126.224-128-109.adsl-dyn.isp.belgacom.be (HELO [192.168.1.13]) ([109.128.224.126]) by relay.skynet.be with ESMTP; 10 Dec 2013 22:45:57 +0100 Subject: Re: Multi-packet gdb server request/response - problem? From: Philippe Waroquiers To: Ivo Raisr Cc: gdb@sourceware.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 Dec 2013 21:46:00 -0000 Message-ID: <1386711973.2226.30.camel@soleil> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00011.txt.bz2 On Tue, 2013-12-10 at 13:22 +0100, Ivo Raisr wrote: > My questions are: > - Is multi-packet request/response supported by gdb? > - In other words, is that gdb's behaviour intentional? > - If yes, then why it cannot handle multi-packet response? > - If no, then is that a bug? Valgrind gdbserver implements (only) the all-stop mode. To my knowledge, with that mode, the principle is that GDB should send one command (such as "s" step), and then should wait for the reply. So, having an "s" packet directly followed by an "m" packet looks strange to me (at least, I never saw this). Does this also happen with the gdbserver included in the GDB distribution ? (be sure GDB is in all stop mode : show non-stop ) When using the Valgrind gdbserver, does the problem also happens if you first instruct GDB to keep the "ack mode" ? i.e. first use set remote noack-packet 0 before launching target remote | vgdb In that mode, GDB and Valgrind gdbserver will continue to have each packet acknowledged using a +. Philippe NB: when GDB is set in non stop mode and connected to the Valgrind gdbserver, it reports that the remote stub does not support non stop mode, but still continues (and that does not work properly after). I am wondering why the choice between all-stop and non-stop is then not automatically "auto choosed/probed" by GDB ?