This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/17223] New: cannot do background execution in scripts
- From: "dje at google dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 01 Aug 2014 18:12:52 +0000
- Subject: [Bug gdb/17223] New: cannot do background execution in scripts
- Auto-submitted: auto-generated
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.