From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10045 invoked by alias); 18 Jun 2005 15:57:51 -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 10036 invoked by uid 22791); 18 Jun 2005 15:57:45 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 18 Jun 2005 15:57:45 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1DjfhW-00017N-6A; Sat, 18 Jun 2005 11:57:42 -0400 Date: Sat, 18 Jun 2005 15:57:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [PATCH] -stack-info-frames Message-ID: <20050618155742.GB3663@nevyn.them.org> Mail-Followup-To: Nick Roberts , Eli Zaretskii , gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17075.57612.684597.392526@farnswood.snap.net.nz> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00286.txt.bz2 On Sat, Jun 18, 2005 at 08:53:32PM +1200, Nick Roberts wrote: > I've talked myself out of implementing -stack-info-frame to give the selected > frame because I thought that "-stack-list-frames 0 0" gave this. Now I see > that it gives the innermost frame where execution has stopped (the current > frame?). I'm not sure that I should have done that because if the user type a > CLI command like "up" in the GUD buffer, I don't see how Emacs could keep > track of the selected frame. Apple's implementation of GDB/MI presumably has > something extra (frame-changed notification?) to do that. Yes, the current frame. Talk to me about this GUD buffer for a second. How does it work - -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) (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" Meanwhile, we don't have this ability. So maybe we do need -stack-info-frame, without an argument. -- Daniel Jacobowitz CodeSourcery, LLC