From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29636 invoked by alias); 12 Apr 2014 00:25:47 -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 29625 invoked by uid 89); 12 Apr 2014 00:25:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: mail-pd0-f170.google.com Received: from mail-pd0-f170.google.com (HELO mail-pd0-f170.google.com) (209.85.192.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 12 Apr 2014 00:25:44 +0000 Received: by mail-pd0-f170.google.com with SMTP id v10so5928059pde.29 for ; Fri, 11 Apr 2014 17:25:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=I2rNynNQg68ib+vqHUup7+2bblujmohIz10VbqCBrZk=; b=GwnTG4a2Lz3P8B1IXb4wl2SrqNPzNiHhdykNXPgwaLVY2px4rbhPpLhrE7v4sPCo2e 1fR1sdt0u7Sj2Y26Tx2BTbD6+XST8ZP9FTKXcPBKE5QtOsDRaC/PGWmNr0imkvWieAH/ KXjAbYndkXX4k+Q4ZmuN5jV0Pz1ZR//+n6FMNiFIAO60ojAGD/H+0Afbdhf+3Q0Xjb1W HTSnTBkhqeLq/odzt/uwJHsBG/5ogTLFA+JWladr0P0ZeN3GW+pkroKOcd43EF/8LSFJ esoz36woyc2XxA/KO3I2tyEUpXuE+Siu8mEkqbNuhDoVg18p7FROMMwWbVgBS3NZOYTX eRcQ== X-Gm-Message-State: ALoCoQlSqiaIW/+gkcFomjqwkLhmrOOqDvFD2a0tjEkax955DFkIXAPibXVLLzkk/TV8t1u6m5uc X-Received: by 10.68.143.34 with SMTP id sb2mr30435103pbb.135.1397262342804; Fri, 11 Apr 2014 17:25:42 -0700 (PDT) Received: from linux (ip72-200-182-56.ri.ri.cox.net. [72.200.182.56]) by mx.google.com with ESMTPSA id t2sm18185232pbq.72.2014.04.11.17.25.41 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 11 Apr 2014 17:25:42 -0700 (PDT) Date: Mon, 14 Apr 2014 06:25:00 -0000 From: Bob Rossi To: Andrew Burgess Cc: gdb@sourceware.org Subject: Re: MI async status output Message-ID: <20140412002538.GA27657@linux> References: <20140409210803.GA3166@linux> <5346B226.40209@cs.msu.su> <20140410201259.GA15060@linux> <5347BD84.5030200@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5347BD84.5030200@broadcom.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00042.txt.bz2 On Fri, Apr 11, 2014 at 11:01:40AM +0100, Andrew Burgess wrote: > On 10/04/2014 9:12 PM, Bob Rossi wrote: > > On Thu, Apr 10, 2014 at 07:00:54PM +0400, Vladimir Prus wrote: > >> On 10.04.2014 01:08, Bob Rossi wrote: > >>> I'm writing unit tests for my MI parser and was trying to get > >>> GDB to output some out of band, async records of type: > >>> status-async-output. > > ... > >>> Does anyone have a simple recipe for getting GDB to output some > >>> async status output? > >> > >> I think the only case where "+" notification is used is load command > >> with sufficiently big binary. See mi-main.c:mi_load_progress. I don't > >> know whether it can be triggered without bare-metal target. > > > > It's unobvious to me how to get GDB to trigger this functionality. > > > > I'd be greatful if anyone could show a quick example getting code > > coverage on GDB where the mi-main.c:mi_load_progress code is hit > > which outputs the > > fputs_unfiltered ("+download", raw_stdout); > > lines (or similiar async status output in GDB). > > It's triggered as part of the progress update for MI loads. The > progress callback is called at least, for each section that is > loaded. > > I did the this: > > 1. Build hello-world test program, which contained at least a .text and > .data section. > 2. Start gdbserver as: gdbserver :1234 helloworld.exe > 3. Start gdb as: gdb -i mi helloworld.exe > 4. Within gdb: > (gdb) -target-select remote :1234 > (gdb) -target-download > # Bunch of +download lines > # Single ^done line. Thanks! Unfortunately, GDB is dumping invalid MI here. When I run -target-download, I get this: ... +download,{section=".interp",section-size="28",total-size="2466"} ... ^done... (gdb) The MI rules are: 1) +download,{section=".interp",section-size="28",total-size="2466"} ^ (+ eaten here) status-async-output ==> [ token ] "+" async-output nl 2) +download,{section=".interp",section-size="28",total-size="2466"} ^ (download eaten by async-class) async-output ==> async-class ( "," result )* async-class ==> "stopped" | others (where others includes download i guess) 3) +download,{section=".interp",section-size="28",total-size="2466"} ^ (, eaten here) async-output ==> async-class ( "," result )* 4) Error here: result must start with a variable name. +download,{section=".interp",section-size="28",total-size="2466"} ^ (syntax error) result ==> variable "=" value variable ==> string Did I find a bug or is this well known behavior of GDB and MI? If it's well known behavior, can anyone explain it? It's possible that result could be just a 'value' instead of 'variable = value'. In this case that would solve the problem perhaps. Any advice would be appreciated. Thanks, Bob Rossi