Re: difference in non-stop/async behaviour, terminal vs script

[Pedro Alves <pedro at codesourcery dot com>]

On Thursday 22 January 2009 07:50:48, Doug Evans wrote:
> Hi.  What should the effect of this script be?
> 
> set non-stop on
> set target-async on
> set auto-solib-add off
> break main
> run
> sharedlib mumble
> break mumble.cc:42
> 

> In cvs head the part of the script after "run" is executed _before_
> the program stops at main, whereas if you type that in at the keyboard
> things work as expected: sharedlib/break are executed _after_ the
> program stops at main.  It's like "run" appearing in scripts is
> equivalent to"run&".

Yeah, this is a known limitation of async mode.  Basically, if there's
a difference in user visible behaviour like this one between sync/async
mode, I tend to consider it a bug.  This particular case is only visible
on the CLI, as with MI/async, execution commands are background
commands always.

If you run the testsuite in async mode, you'll see this trigger
on the define.exp test, more specifically:

 Running ../../../src/gdb/testsuite/gdb.base/define.exp ...
 FAIL: gdb.base/define.exp: use user command: nextwhere

That's basically:

 define nextwhere
   next
   bt
 end

When running a foreground execution command on the terminal, we add
a continuation to the thread the command is being applied on, and
then go back to the event loop, waiting for the next target event.
To prevent the user from typing more commands, sync_execution is set
to 1, the gdb prompt is disabled, and stdin is temporarily removed as
a source from the event loop.  After all the target events of interest
have been handled, stdin is restored back as an event source, and the
prompt is redisplayed.

Now, when running execution commands in a script, the above
doesn't work --- after installing the continuation, we return
immediately, but, the scripts handling code will happily carry on with
the next command without waiting for the current execution command
to complete.

As always, there are several paths to take to fix this,
but they all seem to have cans of worms waiting to be opened.

Say, we could have a "global script continuation" list, were we'd
store the list of commands to execute after the current execution
command finishes (after "run" is done in your case).

Or, play with multiple/stacked event loops, start a new event loop
thus the rest of the unprocessed yet commands are naturally continued
when the current event loop returns.;

Or, make it so that foreground execution commands are blocking
somewhere, perhaps on the target side (keep in mind that the general direction
with the async mode, has been since it's inception, to remove
all blocking from the target side itself, so that may be a step back).

Or, other...  I'd love to see this properly fixed.  :-)

Cases to consider are top level scripts (gdb -x, .gdbinit, source),
breakpoints commands --- although currently, if there's a command that resumes
in target in a breakpoint command list, gdb just discards all commands
after that --- , and user defined commands ("define").

> btw, it seems like for scripting purposes there should be a "wait"
> command (akin to "wait" in bash), for situations like "run&".

-- 
Pedro Alves