Re: [Archer] Re: plan for python inferiors, threads, and events

[Joel Brobecker <brobecker at adacore dot com>]

> With 100+ threads in some processes, it's not easy to figure out
> which thread one wants to look at ...
> 
> So I figured I'd just ask gdb.threads() for a list of threads, search
> our live threads list for a matching thread, and print its name.
> 
> But all gdb.threads() gives me is just a list of 1, 2, 3, 5, ...
> gdb thread IDs, useless for what I want to do :(

We had the same sort of issue in Ada. Ada provides a high-level entity
for concurrent programing called tasks. A tasks carries a lot of
semantic information, including its name, that the ada-tasks module
in GDB is able to print.  This information is extracted from a known
symbol, which is an array of pointers to an Ada_Task_Control_Block.
The tricky part was to identify, for each task, the underlying
thread in GDB's thread list (from "info threads") - we need that
because we use the thread layer to perform task switching.  For
instance, if the user is currently inspecting task 1, whose associated
thread is thread 1, and requests a switch to task 2, then GDB
needs to determine that the thread associated to task 2 is thread N
and then request a switch to that thread.

In practice, the way it is implemented is a little bit different
as we don't compute the index of the thread, but the ptid of the
Ada tasks.  The Ada_Task_Control_Block contains some information
about thread that was spawned (tid and/or lwp), and we use that
information to sinthesize the task's ptid which must correspond
to the associated thread's ptid. Thread switching is then performed
by requesting a switch to the given ptid.

Perhaps there is something similar you can do. You could maybe even
exploit the gdbarch methods that the ada-tasks module uses to
determine the task ptid - the data about live threads that you
maintain is probably similar in some ways to GNAT's table of ATCB.

-- 
Joel