Re: breakpoint commands no more working due to MI front-end

[Jim Ingham <jingham at apple dot com>]

At Apple, we chose to have the breakpoint commands treated as a list  
of CLI commands.  We emit the breakpoint commands output as console  
output from gdb (with the ~"..." form) this way it goes to the gdb  
console in Xcode, which is where we've trained folks to look for it...

Recently, we've also added support in Xcode to do a lot of this, more  
along the lines of what Daniel was suggesting.  So we have log  
actions that are run from Xcode after the stop, and you can tell  
Xcode to continue, etc...  All this requires no support for  
breakpoint commands through the MI, and works quite well.  But still  
if you have complicated tasks you want to perform in the breakpoint  
command (like switch on values in the target or whatever) it is  
useful to write bare gdb commands.  Xcode still allows you to do that  
- though I must admit this is mostly because I had already made it  
work through the MI long before the Xcode guys got around to  
implementing their version.

Anyway, here's how it looks from the mi side:

$ gdb ./gdb
...
(top-gdb) break captured_main
Breakpoint 3 at 0x23a64: file ../../gdb/src/gdb/main.c, line 156.
(top-gdb) commands 3
Type commands for when breakpoint 3 is hit, one per line.
End with a line saying just "end".
>print argc
>continue
>end
(top-gdb) set interpreter mi
-exec-run
~"[Switching to process 6350 local thread 0xf03]\n"
^running
(gdb)
~"$1 = 0"
~"\n"
~"Continuing.\n"
^continuing
*started,reason="breakpoint-command"
GNU gdb 6.3.50.20050815-cvs (Fri Jan 13 22:09:42 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "powerpc-apple-darwin8.3.0".
No symbol table is loaded.  Use the "file" command.

(gdb)

Note we had to emit "*started" to tell Xcode that the target had  
continued from the breakpoint command.  If there were no "continue"  
in the command, you would have gotten a "*stopped".  The  
"^continuing" is a wart that I put in for the Xcode guys at one  
point.  I even forget why they wanted it now.  The main thing is the  
*started...

All the code to get this working is in the Apple gdb.  Yet another  
thing that would probably be worth working into a form where we could  
submit it back, but sadly I don't see the time in my schedule to do  
this in the next year at least.  But it did take a little head  
scratching to get it all working correctly, so if anybody wants to  
take this on, you might want to glance at that first.

Jim


On Jan 23, 2006, at 9:58 AM, Daniel Jacobowitz wrote:

> On Mon, Jan 23, 2006 at 12:53:59PM -0500, Bob Rossi wrote:
> > I think not allowing this would severaly limit the use of GDB for  
> > a lot
> > of users. People in general already have an entire set of breakpoint
> > commands written. I don't think it would be a good idea to make the
> > users translate these commands to a FE specific format, especially
> > since each front end would be different.
>
> Then what should GDB do?  Treat the command list as CLI commands or
> current interpreter commands?  How about the poster's original issue:
> should their output come out before the *stopped?  After?  Replacing
> it?
>
> That's why I called it presently poorly defined :-)
>
> --
> Daniel Jacobowitz
> CodeSourcery