Update thread list, when calling find_global_thread_id

  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
  

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