Message ID | DEC42497C6A9034CAD2685219EF0AD2CF57CF8@DEFTHW99EH4MSX.ww902.siemens.net |
---|---|
State | New, archived |
Headers |
Received: (qmail 123037 invoked by alias); 31 Jul 2018 06:50:07 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 123010 invoked by uid 89); 31 Jul 2018 06:50:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, HTML_MESSAGE, SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:alternative, H*c:HHH X-HELO: thoth.sbs.de Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 31 Jul 2018 06:50:04 +0000 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id w6V6o1wr007400 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <gdb-patches@sourceware.org>; Tue, 31 Jul 2018 08:50:01 +0200 Received: from DEFTHW99ERNMSX.ww902.siemens.net (defthw99ernmsx.ww902.siemens.net [139.22.70.141]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id w6V6o1U9013989 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <gdb-patches@sourceware.org>; Tue, 31 Jul 2018 08:50:01 +0200 Received: from DEFTHW99ERBMSX.ww902.siemens.net (139.22.70.76) by DEFTHW99ERNMSX.ww902.siemens.net (139.22.70.141) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 31 Jul 2018 08:50:00 +0200 Received: from DEFTHW99EH4MSX.ww902.siemens.net ([169.254.2.99]) by DEFTHW99ERBMSX.ww902.siemens.net ([139.22.70.76]) with mapi id 14.03.0408.000; Tue, 31 Jul 2018 08:50:00 +0200 From: "Mangold, Kevin" <kevin.mangold@siemens.com> To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> Subject: [PATCH] Update thread list, when calling find_global_thread_id Date: Tue, 31 Jul 2018 06:49:59 +0000 Message-ID: <DEC42497C6A9034CAD2685219EF0AD2CF57CF8@DEFTHW99EH4MSX.ww902.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable |
Commit Message
Mangold, Kevin
July 31, 2018, 6:49 a.m. UTC
From 0786784a6b216bf42fc5fc5013541ba79ec74cba Mon Sep 17 00:00:00 2001
From: Mangold <kevin.mangold@siemens.com>
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(-)
--
2.17.1.windows.2
Comments
On 2018-07-31 02:49, Mangold, Kevin wrote: > From 0786784a6b216bf42fc5fc5013541ba79ec74cba Mon Sep 17 00:00:00 2001 > From: Mangold <kevin.mangold@siemens.com> > 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
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;