From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126831 invoked by alias); 3 Jan 2019 03:48:37 -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 126821 invoked by uid 89); 3 Jan 2019 03:48:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=death, sense X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 03 Jan 2019 03:48:35 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id x033mSLq031674 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 2 Jan 2019 22:48:33 -0500 Received: by simark.ca (Postfix, from userid 112) id C2FC21E7AF; Wed, 2 Jan 2019 22:48:28 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 2B7B61E05F; Wed, 2 Jan 2019 22:48:28 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 03 Jan 2019 03:48:00 -0000 From: Simon Marchi To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [RFA/commit] GDB crash re-running program on Windows (native) In-Reply-To: <20190103033347.GD28188@adacore.com> References: <20181231035750.8063-1-brobecker@adacore.com> <2c42b3197a35871cbc92d564f1772922@polymtl.ca> <20190103033347.GD28188@adacore.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00055.txt.bz2 On 2019-01-02 22:33, Joel Brobecker wrote: > 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? Yes, thanks for the explanation, everything LGTM. Simon