This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: async implies sync


 > > define.exp fails with the script nextwhere.  Asynchronous operation means
 > > that it tries to do `where' before 'next' has finished.  Perhaps scripts
 > > should be forced to run synchronously.
 > 
 > Hmm, boy, that's a good point.  In fact, you know what?
 > I think we need some sort of synchronization primatives, 
 > since the target and gdb can now run in parallel.
 > 
 > Every time we do a step/next/continue/until, and come
 > back to the gdb prompt before the target has stopped, 
 > we've effectively done a "fork".  At an absolute minimum, 
 > I think we need a "join" or a "wait".

Some commands can sensibly be executed while the target is running e.g pwd,
"show height", etc.  Currently GDB only allows a few CLI commands (see top.c).
Most CLI commands report:

  Cannot execute this command while the target is running.

GDB allows no MI commands apart from -exec-interrupt (see mi-main.c) and
reports:

  Cannot execute command interpreter-exec while target running

At some stage more commands should be allowed but the above messages make
sense in interactive use.

Currently GDB reports when execution has stopped by outputting "*stopped,..".
Isn't this equivalent to your "join"?

Perhaps Apple can say what they do for scripts.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]