On 2025-06-05 18:57, Tom Tromey wrote:
> 
> I'm not quite as sure about the last one.  This test sets a couple of
> breakpoints that have 'commands', where the commands delete the
> breakpoint, like:
> 
> [ break main.adb:4 then ... ]
>         "silent",
>         'printf "Breakpoint hit #1.\\n"',
>         "clear main.adb:4",
>         "continue",
>         "end",
> 
> When running the expected output is seen but gdb says:
> 
>     (gdb) run
>     Starting program: C:\[...]
>     Breakpoint hit #1.
>     Breakpoint hit #2.
>     No unwaited-for children left.
> 
> It's that last line that causes the problem.  The test expects an "exit
> notification", which is kind of complicated in this test suite, but I
> think for native testing boils down to a message like "[Inferior
> ... exited ...]".
> 
> I see this "unwaited-for" text in infrun.c.  But I wonder if this is
> really intended.

Hmm, I'm not sure how you're seeing that.  That is the output of a TARGET_WAITKIND_NO_RESUMED
event.  But it can also be a TARGET_WAITKIND_THREAD_EXITED, which GDB treats as
TARGET_WAITKIND_NO_RESUMED in some cases, but only if the target backend is not in non-stop mode.

In any case, TARGET_WAITKIND_NO_RESUMED means that infrun now believes that the target
has no resumed threads left running, so if it went back to waiting for events, it
would be stuck there forever, as no thread would ever report an event -- none is resumed.

"No unwaited-for children left" is the text I came up with back when I added 
TARGET_WAITKIND_NO_RESUMED, and I based it on "man waitpid", which says:

 ERRORS
        ECHILD (for wait()) The calling process does not have any unwaited-for children.

I kind of regret it, though.  Something like "No resumed threads left." would be
probably clearer and less implementer-speak.

Is the test using scheduler locking (and was previously ignoring the error
that "set scheduler-locking on" currently issues on Windows) ?

I ask because that is expected output if you continue with scheduler locking enabled,
and the thread exits.  E.g., the new gdb.threads/leader-exit-schedlock.exp testcase added
by the series, has:

 Thread 1 "leader-exit-schedlock" hit Breakpoint 2, main () at /home/alves/rocm/gdb/src/gdb/testsuite/gdb.threads/leader-exit-schedlock.c:55
 55        return 0; /* break-here */
 (gdb) PASS: gdb.threads/leader-exit-schedlock.exp: target-non-stop=off: exit-threads-first=0: schedlock=on: continue to breakpoint: break-here
 set scheduler-locking on
 (gdb) PASS: gdb.threads/leader-exit-schedlock.exp: target-non-stop=off: exit-threads-first=0: schedlock=on: set scheduler-locking on
 c
 Continuing.
 [Thread 11496.0x150 exited]
 No unwaited-for children left.

But I don't suppose your test was really doing that.

Maybe some logs like:

 set debug infrun
 set debugevents on
 set debugexceptions on
 set debugexec on

would help see what's going on.

I wrote a new testcase based on your description, see attached.  It passes cleanly here.

Can you help pointing me to what would need to be changed in the test to make it closer to the AdaCore test?

Pedro Alves