Re: [PATCH] Return correct thread for cached event

[Pedro Alves <pedro@palves.net>]

On 2026-09-02 19:09, Tom Tromey wrote:
> Commit 2e1aacf15a9 ("Windows gdb+gdbserver: Make current_event
> per-thread state") introduced a regression.  This was detected by the
> AdaCore internal test suite in a somewhat unusual configuration: when
> using "attach" with a 32-bit Windows process, an extra stop would be
> generated, like:
> 
>     (gdb) break break_me
>     Breakpoint 1 at 0x1211a04: file pck.adb, line 18.
>     (gdb) continue
>     Continuing.
> 
>     Thread 4 received signal SIGINT, Interrupt.
>     [Switching to thread 4 (Thread 6652)]
>     0x77034210 in ntdll!RtlUserThreadStart () from C:/Windows/SysWOW64/ntdll.dll
> 
> Here, we expect to stop in break_me, but instead stop in some Windows
> DLL.
> 
> I tracked this down to this hunk in the aforementioned commit:
> 
> -      return debug_event_ptid (&windows_process.current_event);
> +      return ptid_t (windows_process.process_id,
> +		     windows_process.main_thread_id, 0);
> 
> What happens here is that the "cached" stop ends up being reported in
> the main thread, rather than whatever thread actually caused this
> stop.

Ouch, sorry about this.  And thanks for all the investigation.

I must have very early on in the non-stop work assumed that the initial events
all come from the main thread, but later on I learned that they don't (I even
ran into that very nasty bug that led to the state => internal_state split), and
missed this assumption here.

> 
> This patch fixes the problem by arranging to also cache the thread
> ptid.
> 
> I am not sure whether the call to switch_to_thread here is really
> needed; but since other returns seem to switch the thread, I thought
> this one ought to as well.
> 
> I tested this using the AdaCore internal test suite.
> 
> As this is a regression, when it lands I also plan to apply it to the
> gdb 18 branch.
> 
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34583

Approved-by: Pedro Alves <pedro@palves.net>