From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117403 invoked by alias); 31 Jul 2018 14:37: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 117393 invoked by uid 89); 31 Jul 2018 14:37:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=reaching 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; Tue, 31 Jul 2018 14:37:55 +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 w6VEbme9018314 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 31 Jul 2018 10:37:53 -0400 Received: by simark.ca (Postfix, from userid 112) id 9E42A1EF29; Tue, 31 Jul 2018 10:37:48 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id B21E91E077; Tue, 31 Jul 2018 10:37:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 31 Jul 2018 14:37:00 -0000 From: Simon Marchi To: "Mangold, Kevin" Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Update thread list, when calling find_global_thread_id In-Reply-To: References: Message-ID: <30791510bc139669242c49fff0be9549@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00813.txt.bz2 On 2018-07-31 02:49, Mangold, Kevin wrote: > From 0786784a6b216bf42fc5fc5013541ba79ec74cba Mon Sep 17 00:00:00 2001 > From: Mangold > Date: Tue, 31 Jul 2018 08:41:14 +0200 > Subject: [PATCH] Update Thread List when searching for global ID > > When gdb is used within Eclipse with enabled reverse debugging, > when going back after thread creation, the thread list is not > accurate anymore and eclipse throw some errors. So we need to update > the thread list, when calling the function 'find_thread_global_id'. > > gdb/Changelog > > * thread.c: add update_thread_list() inf function > find_thread_global_id > --- > gdb/thread.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/thread.c b/gdb/thread.c > index aadbf935f5..4c746dcedf 100644 > --- a/gdb/thread.c > +++ b/gdb/thread.c > @@ -514,7 +514,7 @@ struct thread_info * > find_thread_global_id (int global_id) > { > struct thread_info *tp; > - > + update_thread_list(); > for (tp = thread_list; tp; tp = tp->next) > if (tp->global_num == global_id) > return tp; > -- > 2.17.1.windows.2 Hi Kevin, Since GDB's reverse implementation does not work with multi-threaded programs, I assume you are seeing this problem with rr, since you mentioned it in your other patch. It would be good to mention that in the commit message. find_thread_global_id is really meant to find a thread in GDB's internal data structures. Calling update_thread_list is expensive, reaching out to the remote target, so we don't want to do it every time we look up a thread by id. What we probably want to do is call update_thread_list when the target stops (where the thread list may have changed). This way, we only do it once until the next stop. If GDB's knowledge of the threads is not in sync with the actual threads on the target, it could mean we missed calling it at the last stop. For reference, the call to update_thread_list in normal_stop takes care of syncing GDB's notion of the target threads when stopping "normally". Maybe this is not done in the reverse case (just because this has never been encountered before), I haven't checked in depth. That would need to be investigated. Thanks, Simon