From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10157 invoked by alias); 9 Dec 2019 15:09:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 10149 invoked by uid 89); 9 Dec 2019 15:09:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=alright, maint X-HELO: mx1.osci.io Received: from polly.osci.io (HELO mx1.osci.io) (8.43.85.229) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Dec 2019 15:09:11 +0000 Received: by mx1.osci.io (Postfix, from userid 994) id 1065C20422; Mon, 9 Dec 2019 10:09:09 -0500 (EST) Received: from gnutoolchain-gerrit.osci.io (gnutoolchain-gerrit.osci.io [8.43.85.239]) by mx1.osci.io (Postfix) with ESMTP id C06EC20300; Mon, 9 Dec 2019 10:09:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by gnutoolchain-gerrit.osci.io (Postfix) with ESMTP id A35B620AF6; Mon, 9 Dec 2019 10:09:06 -0500 (EST) X-Gerrit-PatchSet: 2 Date: Mon, 09 Dec 2019 15:09:00 -0000 From: "Tankut Baris Aktemur (Code Review)" To: gdb-patches@sourceware.org Cc: Pedro Alves , Luis Machado Auto-Submitted: auto-generated X-Gerrit-MessageType: comment Subject: [review v2] infrun: handle already-exited threads when attempting to stop X-Gerrit-Change-Id: I7cec98f40283773b79255d998511da434e9cd408 X-Gerrit-Change-Number: 133 X-Gerrit-ChangeURL: X-Gerrit-Commit: a32b3dcee11cd3a9f40c5f07757a514074b9051f In-Reply-To: References: X-Gerrit-Comment-Date: Mon, 9 Dec 2019 10:09:06 -0500 Reply-To: gnutoolchain-gerrit@osci.io MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Disposition: inline User-Agent: Gerrit/3.0.3-79-g83ff7f88f1 Content-Type: text/plain; charset=UTF-8 Message-Id: <20191209150906.A35B620AF6@gnutoolchain-gerrit.osci.io> X-SW-Source: 2019-12/txt/msg00337.txt.bz2 Tankut Baris Aktemur has posted comments on this change. Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/133 ...................................................................... Patch Set 2: (1 comment) > Patch Set 2: > > (1 comment) | --- gdb/infrun.c | +++ gdb/infrun.c | @@ -4494,7 +4509,19 @@ stop_all_threads (void) | + if (ws.kind == TARGET_WAITKIND_THREAD_EXITED) | + delete_thread (t); | + else | + { | + /* TARGET_WAITKIND_EXITED or | + TARGET_WAITKIND_SIGNALLED. */ | + /* Need to restore the context because | + handle_inferior_exit switches it. */ | + scoped_restore_current_pspace_and_thread restore; | + handle_inferior_exit (event_ptid, ws); PS2, Line 4518: > The fix for this I think must be around leaving the TARGET_WAITKIND_EXITED/TARGET_WAITKIND_SIGNALLED event pending, so that it is processed later when we're out of the stop_all_threads loop and back to dequeuing the next event. I'd like to ask for your opinion on making the second exit event pending. One problem is, because the event has not been reported to the user yet, the user still thinks that the inferior is alive. So, after getting the prompt because of the first exit event, they may be tempted to do "info threads" or switch to the not-yet-reported- inferior and inspect its state. This triggers a query (e.g. of registers) on the process that is already gone. I tried the following scenario with the current master branch (the patch that I proposed was not applied): ~~~ $ gdb ./a.out (gdb) maint set target-non-stop off (gdb) start ... (gdb) add-inferior -exec ./a.out [New inferior 2] Added inferior 2 ... (gdb) inferior 2 [Switching to inferior 2 [] (/tmp/a.out)] (gdb) start ... (gdb) set schedule-multiple on (gdb) c Continuing. [Inferior 2 (process 16331) exited normally] (gdb) i inferiors Num Description Executable 1 process 16137 /tmp/a.out * 2 /tmp/a.out (gdb) inferior 1 [Switching to inferior 1 [process 16137] (/tmp/a.out)] [Switching to thread 1.1 (process 16137)] Couldn't get registers: No such process. (gdb) i threads Id Target Id Frame Couldn't get registers: No such process. (gdb) c Continuing. Couldn't get registers: No such process. ~~~ If I save the exit event in my patch as a pending event (and omit 'maint set target-non-stop off'), I get essentially the same problem. What is the expected GDB behavior here? Would it be alright to actually print both exit events, followed by the gdb-prompt, where the user can now query $_exitcode or $_exitsignal by switching between inferiors, assuming those special variables are set correctly per inferior? | + } | + } | } | else | { | thread_info *t = find_thread_ptid (event_ptid); | if (t == NULL) | t = add_thread (event_ptid); | -- Gerrit-Project: binutils-gdb Gerrit-Branch: master Gerrit-Change-Id: I7cec98f40283773b79255d998511da434e9cd408 Gerrit-Change-Number: 133 Gerrit-PatchSet: 2 Gerrit-Owner: Tankut Baris Aktemur Gerrit-Reviewer: Luis Machado Gerrit-Reviewer: Pedro Alves Gerrit-Reviewer: Tankut Baris Aktemur Gerrit-Comment-Date: Mon, 09 Dec 2019 15:09:06 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Pedro Alves Comment-In-Reply-To: Tankut Baris Aktemur Gerrit-MessageType: comment