From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22238 invoked by alias); 1 Aug 2014 18:12:55 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 22211 invoked by uid 48); 1 Aug 2014 18:12:55 -0000 From: "dje at google dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/17223] New: cannot do background execution in scripts Date: Fri, 01 Aug 2014 18:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dje at google dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q3/txt/msg00205.txt.bz2 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.