From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22524 invoked by alias); 18 Jun 2005 22:48:44 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22323 invoked by uid 22791); 18 Jun 2005 22:48:40 -0000 Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 18 Jun 2005 22:48:40 +0000 Received: from farnswood.snap.net.nz (p136-tnt1.snap.net.nz [202.124.110.136]) by viper.snap.net.nz (Postfix) with ESMTP id 6853A543CE6; Sun, 19 Jun 2005 10:48:36 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 67DEB62A9A; Sat, 18 Jun 2005 23:49:30 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17076.42233.730605.834264@farnswood.snap.net.nz> Date: Sat, 18 Jun 2005 22:48:00 -0000 To: Daniel Jacobowitz Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [PATCH] -stack-info-frames In-Reply-To: <20050618155742.GB3663@nevyn.them.org> References: <17075.21529.964955.923197@farnswood.snap.net.nz> <20050617230130.GB21178@nevyn.them.org> <20050617231425.GA22254@nevyn.them.org> <17075.30993.384316.356236@farnswood.snap.net.nz> <20050618015756.GA30430@nevyn.them.org> <17075.57612.684597.392526@farnswood.snap.net.nz> <20050618155742.GB3663@nevyn.them.org> X-SW-Source: 2005-06/txt/msg00289.txt.bz2 > Talk to me about this GUD buffer for a second. How does it work - > -interpreter-exec? Currently I input CLI commands directly but I know that the plan is to remove this capability and just leave "-interpreter-exec" > I think it's becoming clear that we need to have the MI output for > commands whether or not we also have the CLI output. Right now we've > got these: > > (gdb) > up > &"up\n" > ^done,frame={level="2",addr="0x0813f48d",func="gdb_wait_for_event",args=[],file="/big/fsf/local/src/gdb/event-loop.c",line="753"},line="753",file="/big/fsf/local/src/gdb/event-loop.c" > (gdb) This is what used to happen (I get this with GNU gdb 5.2.1-2mdk, for example) But now with GDB in CVS, I get the same output as with "-interpreter-exec console up" (apart from "up\n" in the log stream) i.e. up &"up\n" ~"#1 0x08048641 in main (argc=1, argv=0xbffff794) at myprog.c:81\n" ~"81\t myprint (i,a[i] /* hello */);\n" ^done I don't know why you don't also get this. > (gdb) > -interpreter-exec console up > ~"#1 0xb7d621ae in poll () from /lib/tls/i686/cmov/libc.so.6\n" > ^done > > But wouldn't this be better? > > (gdb) > -interpreter-exec console up > ~"#1 0xb7d621ae in poll () from /lib/tls/i686/cmov/libc.so.6\n" > ^done,frame={level="2",addr="0x0813f48d",func="gdb_wait_for_event",args=[],file="/big/fsf/local/src/gdb/event-loop.c",line="753"},line="753",file="/big/fsf/local/src/gdb/event-loop.c" Yes. The same is true for the commands that control execution: (gdb) -exec-next ^running (gdb) *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x080484dd",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff794"}],file="myprog.c",fullname="/home/nick/myprog.c",line="50"} (gdb) but (gdb) -interpreter-exec console next ~"50\t int n1=7, n2=8, n3=9;\n" ^done (gdb) doesn't give the frontend any information. Before I looked at the code, I presumed that GDB detected when execution had stopped and the printed out "*stopped" (in which case this would happen also with CLI commands). Looking at it, I see it is printed in mi_execute_async_cli_command so that it appears as command output rather than event notification > Meanwhile, we don't have this ability. So maybe we do need > -stack-info-frame, without an argument. Yes, unless Apple's proposed merge will provide the necessary information. Nick