From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96369 invoked by alias); 3 Jan 2019 03:33:56 -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 96354 invoked by uid 89); 3 Jan 2019 03:33:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=propose, death, sense X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 03 Jan 2019 03:33:53 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 2C75B117544; Wed, 2 Jan 2019 22:33:52 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id X1uHCXMzTW8w; Wed, 2 Jan 2019 22:33:52 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B66FD117531; Wed, 2 Jan 2019 22:33:51 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 57526867B9; Thu, 3 Jan 2019 07:33:47 +0400 (+04) Date: Thu, 03 Jan 2019 03:33:00 -0000 From: Joel Brobecker To: Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [RFA/commit] GDB crash re-running program on Windows (native) Message-ID: <20190103033347.GD28188@adacore.com> References: <20181231035750.8063-1-brobecker@adacore.com> <2c42b3197a35871cbc92d564f1772922@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2c42b3197a35871cbc92d564f1772922@polymtl.ca> User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2019-01/txt/msg00054.txt.bz2 Hi Simon, Thanks for the review! > > With that in mind, this commit fixes the issue by deleting the thread > > when the inferior sends the exit-process event as opposed to deleting it > > later, while starting a new inferior. > > > > This restores also restores the printing of the thread-exit notification > > "This restores also restores" > > > for the main thread, which was missing before. Looking at the transcript > > of the example show above, we can see 4 thread creation notifications, > > and only 3 notifications for thread exits. Now creation and exit > > notifications are balanced. > > Another choice is to not show the main thread's creation and exit (as is > done on Linux), since it's kind of redundant with the process creation and > exit. Indeed, that's a good idea. I propose to work on that as a followup patch, as I am a little short on time these next couple of weeks (broken hand :-(). > > In the handling of EXIT_THREAD_DEBUG_EVENT, the main_thread_id > > check is removed because deemed unnecessary: The main thread was > > introduced by a CREATE_THREAD_DEBUG_EVENT, and thus the kernel > > is expected to report its death via EXIT_PROCESS_DEBUG_EVENT. > > Should that last EXIT_PROCESS_DEBUG_EVENT actually be > EXIT_THREAD_DEBUG_EVENT? Not quite, but actually a good question nonetheless. There was an auto-completion error in the text above. New text: | In the handling of EXIT_THREAD_DEBUG_EVENT, the main_thread_id | check is removed because deemed unnecessary: The main thread was | introduced by a CREATE_PROCESS_DEBUG_EVENT, and thus the kernel | is expected to report its death via EXIT_PROCESS_DEBUG_EVENT. In other words, we don't expect to receive an EXIT_THREAD_DEBUG_EVENT for the main thread, because, at the Windows level, that thread really isn't a thread, but really a process. > > @@ -1607,6 +1599,9 @@ get_windows_debug_event (struct target_ops *ops, > > } > > else if (saw_create == 1) > > { > > + windows_delete_thread (ptid_t (current_event.dwProcessId, 0, > > + main_thread_id), > > + 0); > > ourstatus->kind = TARGET_WAITKIND_EXITED; > > ourstatus->value.integer = current_event.u.ExitProcess.dwExitCode; > > thread_id = main_thread_id; > > If what you said above is right (that the kernel reports the main thread's > death through an EXIT_THREAD_DEBUG_EVENT), why is this new call to > windows_delete_thread needed? Shouldn't it already be deleted at this > point? Does the answer above allow us to make sense of this hunk? -- Joel