public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug gdb/17223] New: cannot do background execution in scripts
@ 2014-08-01 18:12 dje at google dot com
2014-08-01 19:19 ` [Bug gdb/17223] " dje at google dot com
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: dje at google dot com @ 2014-08-01 18:12 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17223
Bug ID: 17223
Summary: cannot do background execution in scripts
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: dje at google dot com
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
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug gdb/17223] cannot do background execution in scripts
2014-08-01 18:12 [Bug gdb/17223] New: cannot do background execution in scripts dje at google dot com
@ 2014-08-01 19:19 ` dje at google dot com
2014-08-01 19:51 ` dje at google dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: dje at google dot com @ 2014-08-01 19:19 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17223
--- Comment #1 from dje at google dot com ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug gdb/17223] cannot do background execution in scripts
2014-08-01 18:12 [Bug gdb/17223] New: cannot do background execution in scripts dje at google dot com
2014-08-01 19:19 ` [Bug gdb/17223] " dje at google dot com
@ 2014-08-01 19:51 ` dje at google dot com
2014-08-01 19:58 ` dje at google dot com
2015-01-14 9:18 ` palves at redhat dot com
3 siblings, 0 replies; 5+ messages in thread
From: dje at google dot com @ 2014-08-01 19:51 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17223
--- Comment #2 from dje at google dot com ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug gdb/17223] cannot do background execution in scripts
2014-08-01 18:12 [Bug gdb/17223] New: cannot do background execution in scripts dje at google dot com
2014-08-01 19:19 ` [Bug gdb/17223] " dje at google dot com
2014-08-01 19:51 ` dje at google dot com
@ 2014-08-01 19:58 ` dje at google dot com
2015-01-14 9:18 ` palves at redhat dot com
3 siblings, 0 replies; 5+ messages in thread
From: dje at google dot com @ 2014-08-01 19:58 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17223
--- Comment #3 from dje at google dot com ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug gdb/17223] cannot do background execution in scripts
2014-08-01 18:12 [Bug gdb/17223] New: cannot do background execution in scripts dje at google dot com
` (2 preceding siblings ...)
2014-08-01 19:58 ` dje at google dot com
@ 2015-01-14 9:18 ` palves at redhat dot com
3 siblings, 0 replies; 5+ messages in thread
From: palves at redhat dot com @ 2015-01-14 9:18 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17223
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com
--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-01-14 9:18 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-01 18:12 [Bug gdb/17223] New: cannot do background execution in scripts dje at google dot com
2014-08-01 19:19 ` [Bug gdb/17223] " dje at google dot com
2014-08-01 19:51 ` dje at google dot com
2014-08-01 19:58 ` dje at google dot com
2015-01-14 9:18 ` palves at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).