Re: [PATCH] Windows gdb: all-stop, interrupt with "stopped" instead of SIGTRAP

[Pedro Alves <pedro@palves.net>]

On 2026-05-05 15:17, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:
> 
> Pedro> Currently, "interrupt" uses DebugBreakProcess (or equivalent), which
> Pedro> injects a new thread in the inferior that executes an int3 instruction
> Pedro> (on x86), which raises a SIGTRAP.  With the target backend in non-stop
> Pedro> mode, its easy to avoid all that and make interrupt in all-stop just
> Pedro> suspend a pre-existing thread and report "stopped", like "set non-stop
> Pedro> on" does (via target_stop).
> 
> Looks reasonable to me, thanks.
> Approved-By: Tom Tromey <tom@tromey.com>
> 

Thanks, merged.

> Pedro> +void
> Pedro> +windows_nat_target::stop (ptid_t ptid)
> Pedro> +{
> Pedro> +  stop_interrupt (ptid, false);
> Pedro> +}
> 
> I guess this didn't land:
> 
> https://sourceware.org/pipermail/gdb-patches/2026-April/226456.html
> 

Oh, I hadn't seen that.  (If it isn't obvious, I haven't been able to keep up with the
list in the past year or so.  I'm hoping that will change soon-ish.)

I had been sitting on this patch until non-stop was in.  Apparently for exactly 3 years! :-P

 commit 88ae0d8325ced6d62781f1838e2bfa6195866929
 Author:     Pedro Alves <pedro@palves.net>
 AuthorDate: Fri May 5 15:51:31 2023 +0100
 Commit:     Pedro Alves <pedro@palves.net>
 CommitDate: Thu May 7 19:32:35 2026 +0100

> but OTOH I think your implementation is more precise.

Yeah, that one ignores the ptid argument completely, and would just make target_stop inject
the magic ctrl-c thread, which is not what the semantics of target_stop should be.

Note "windows_nat_target::stop(ptid_t ptid)" already existed, it was added by the
non-stop support.  This patch is refactoring it to be usable from the interrupt() context.

Thanks,
Pedro Alves