Bug 17223

Summary:	cannot do background execution in scripts
Product:	gdb	Reporter:	dje
Component:	gdb	Assignee:	Not yet assigned to anyone <unassigned>
Status:	NEW ---
Severity:	normal	CC:	pedro
Priority:	P2
Version:	HEAD
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

Description dje 2014-08-01 18:12:52 UTC

Detection of new threads is done in target-async using the event loop.
However, when running a script, or when running multiple commands passed via -ex, etc., the event loop is not used (at least not until gdb gets the keyboard).

Testcase: forever-threads from pr 17147

bash$ cat foo.gdb
set trace-commands on
set non-stop on
file forever-threads
run &
shell sleep 3
info threads
bash$ gdb -x foo.gdb

Note that gdb doesn't become aware of the new threads until after the script completes and gdb gets the keyboard. It also happens that gdb doesn't become aware of shared libs being loaded (including libthread_db) until gdb gets the keyboard.

This happens because script execution is done in its own loop that doesn't check for events (ref: top.c:command_loop).  Plus more would be required to handle foo.gdb being split up into a bunch of -ex options.
Question is: Do we want to support this use-case?  It sure would be nice.

One (not well thought out) thought is to add a command that processes current inferior events.  Maybe (maybe not) it could be built on the hypothetical "wait" command.
ref: https://sourceware.org/gdb/wiki/BackgroundExecution

Comment 1 dje 2014-08-01 19:19:20 UTC

A potential hacky workaround is to feed the script to stdin.
One may need to do "set interactive-mode on".
But see pr 17224, currently trying this segvs.

Comment 2 dje 2014-08-01 19:51:05 UTC

Re: "Plus more would be required ..."
Plus there's things like the "while" command, etc.
Anything that loops processing commands without also processing inferior events.

Comment 3 dje 2014-08-01 19:58:41 UTC

(In reply to dje from comment #1)
> A potential hacky workaround is to feed the script to stdin.
> One may need to do "set interactive-mode on".
> But see pr 17224, currently trying this segvs.

As an experiment, I find I can get gdb to process inferior events if I add enough nops to the script.  E.g., do "info threads", do some mindless things like "pwd", do another "info threads", etc. and slowly the threads start to appear.

In this case stdin is "hogging" the event queue.
IWBN, at least in this case, if inferior events hogged the event queue.
Are there some cases where we want the former and some where we want the latter?
Or can we, for example, keep processing inferior events until there are no more?

It may be that some command ("wait" or whatever) that one can put in a script to explicitly process all current inferior events has sufficient utility to warrant adding.

Comment 4 Pedro Alves 2015-01-14 09:18:39 UTC

Yeah, this is a use case that ideally we'd support.

My original attempt to make async work in scripts relied on continuations and the top level event loop.  That was turning out to be a rat hole, so we ended up with the interpreter flipping async off.  See:

 https://sourceware.org/ml/gdb/2011-08/msg00069.html

> This happens because script execution is done in its own loop that doesn't 
> check for events (ref: top.c:command_loop).

With -x and -ex, it's indeed annoying that those are processed before the top level event loop starts.  However, events do get processed, in maybe_wait_sync_command_done, when the command is foreground, or if the command is foreground, they'll be processed at the next command that blocks, or after the script is all run, whichever comes first.

Here:

 run &
 shell sleep 3
 info threads

We can also say that the problem is with the "shell" command.  It's synchronous, and does it's own blocking "waitpid" instead of going through the event loop.