On 2025-06-12 20:23, Tom Tromey wrote:
> Pedro> Is the test using scheduler locking (and was previously ignoring the error
> Pedro> that "set scheduler-locking on" currently issues on Windows) ?
> 
> Nope.  The test is fairly basic.  I've appended the two files (the test
> script and the Ada source) , since I don't think there's anything
> particularly proprietary about them.  They seem to be pretty old.

Thanks!  Indeed.  It doesn't look that different from what I've tried, then.  I had made the test
use threads just in case it was easier to adapt it that way toward what AdaCore's test was doing,
but I removed all of that now that it's clear it's not necessary, and the result is the same for me.
I've attached the simplified testcase.

You mentioned that you merged my branch into AdaCore's local tree.  I wonder if this is some local change
in the AdaCore gdb that might need some adjustment.  Is it possible to run that test in AdaCore's testsuite
with a GDB straight based on my branch on top of master, instead of AdaCore's local tree?
Like, the equivalent of:

$ make check RUNTESTFLAGS="GDB=/path/to/pedros/gdb" TESTS="gdb.base/continue-break-command.exp"

> 
> Pedro> I ask because that is expected output if you continue with scheduler locking enabled,
> Pedro> and the thread exits.  E.g., the new gdb.threads/leader-exit-schedlock.exp testcase added
> Pedro> by the series, has:
> 
> Pedro> Maybe some logs like:
> Pedro>  set debug infrun
> Pedro>  set debugevents on
> Pedro>  set debugexceptions on
> Pedro>  set debugexec on
> Pedro> would help see what's going on.
> 
> I will try to do this soon.

Thank you!

If you end up debugging this, windows_nat_target::any_resumed_thread() is where we
decide whether to report a TARGET_WAITKIND_NO_RESUMED event.  Maybe that is returning
true in a situation that it shouldn't, for some reason.

Pedro Alves