This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: 'continue' command problem
> 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