>Again, I am not sure that's true. There is certainly one single
>instruction (possibly a syscall) inside pthread_create that commits the
>thread creation, after which the new thread will be visible. If you
>single-step that instruction, you'll have one more thread after stepping
>than you had before.

>And with "set scheduler-locking off", threads other than the one being
>stepped run freely during the step. One of those threads could exit
>during your instruction single step, so you'd miss that.

>If you know that new threads can only appear during a syscall
>instruction (I have no idea, just speculating), then you could perhaps
>check what is the instruction about to be stepped. If it's not a
>syscall instruction, and if the scheduler-locking setting is "on” or
>"step" (nothing else than this thread will run during the step), then
>perhaps it would be safe to skip the thread update. But you'd have to
>check how it really works under the hood.

So, from the scoped_time_it instrumentation instrumentation pthdb_pthread, sync_threadlists, pd_update costs 1.2 seconds roughly in my LPAR. get_signaled_thread, pthdb_pthread_state, pthdb_pthread_tid, pthdb_pthread_ptid, pthdb_session_update are all free. They hardly cost anything.

The very first pthdb_pthread(PTHDB_LIST_FIRST) call inside sync_threadlists costs ~1 second per stop regardless of thread count (same cost with 3 threads as with 20). Everything else is essentially free. That one call is what libpthdebug uses to start enumerating threads, what I mean is it walks all the pthread internal data structures in the inferior process. Skipping sync_threadlists entirely on step stops eliminates that cost completely, giving the 4.2X speedup.

As you noted, stepping over the instruction that commits a pthread_create (or observing another thread exit when scheduler-locking off is in effect) could cause the thread state to change while the step is in progress. So skipping the update unconditionally for every software single-step would not be correct.

However, as you pointed out, doing so unconditionally is not correct. If a step executes the instruction that makes a newly created thread visible, or if another thread exits while scheduler-locking off is in effect, then the thread list can legitimately change during the step. In those cases, skipping the update would cause GDB to miss thread creation and/or thread termination events. I have not yet found a reliable way to avoid this. Now it appears that the real bottleneck is the cost of pthdb_pthread(PTHDB_LIST_FIRST) itself rather than any of the surrounding GDB logic. Given that, I will discuss this with the AIX maintainers to understand better opportunities for improvement. Thanks again for the review and for highlighting the correctness concerns.