Re: 'continue' command problem

[Nick Roberts <nickrob@snap.net.nz>]

 > Ah, sorry, I just called the field "commands".  It's done in  
 > breakpoint.c, in "print_it_typical" (in the Apple sources).

OK, thanks for the info.

 > The way I implemented it, I added a *started message to tell the UI  
 > that we had restarted because of a breakpoint command, as well as a  
 > ^continuing.  I forget exactly why I chose to do it this way, it's  
 > maybe a little overdetermined.  (Note, we also added a -breakpoint- 
 > commands" command to set the breakpoint commands...)
 > 
 > Anyway, this looks like:

 >...
 > (gdb) break 8
 > Breakpoint 1 at 0x1fa1: file main.c, line 8.
 > (gdb) commands 1
 > Type commands for when breakpoint 1 is hit, one per line.
 > End with a line saying just "end".
 >  >print foo
 >  >continue
 >  >end
 > (gdb) set interpreter mi1
 > -exec-run
 > ~"[Switching to process 19582 local thread 0x1103]\n"
 > =shlibs-updated
 > ^running
 > (gdb)
 > ~"$1 = 0"
 > ~"\n"
 > ~"Continuing.\n"
 > ^continuing
 > *started,reason="breakpoint-command"

"breakpoint-command" comes before the first "breakpoint-hit" ?

 > *stopped 
 > ,time 
 > = 
 > {wallclock 
 > = 
 > "0.00153 
 > ",user 
 > = 
 > "0.00046 
 > ",system 
 > = 
 > "0.00098 
 > ",start 
 > ="1182881550.648028",end="1182881550.649559"},reason="breakpoint- 
 > hit",commands="yes",times="2",bkptno="1",thread-id="1"
 > ~"$2 = 1"
 > ~"\n"
 > ~"Continuing.\n"
 > ^continuing
 >...

If Apple GDB can handle command lists, I guess user defined functions work
too.  Isn't asynchronous operation a problem here because the second
command can start executing before the first command has finished?

-- 
Nick                                           http://www.inet.net.nz/~nickrob