Extending linux-thread-db to support user space threads
Niall Douglas
s_sourceforge@nedprod.com
Thu Sep 12 20:24:17 GMT 2024
Hi,
As nothing seemed to come from Tom Tromey's work on supporting green
threads (https://sourceware.org/pipermail/gdb/2022-March/049959.html), I
decided to try extending linux-thread-db to support more than one GDB
thread per LWP. You can find my efforts so far at:
https://github.com/ned14/binutils-gdb/commit/e86072ff6d3c12c97e846baa99f5157cdd9b17fc
I have taken a different approach to Tom, who added an additional thread
backend which had Python scripting tell GDB about the green threads.
Instead, mine relies on the GDB user supplying a custom
`libthread_db.so.1` which overlays on top of the NPTL `libthread_db.so`
to additionally supply what userspace threads there are. If
linux-thread-db finds system threads being returned by
`libthread_db.so.1`, it'll then additionally ask `td_ta_thr_iter()` for
threads with state `TD_THR_RUN` (i.e. user space threads only) whenever
the list of threads needs updating.
If all this sounds a bit complicated, there is a test case in the commit
above which compiles a test `libthread_db.so` wrapper and shows the
concept in action.
Where I'm a bit stuck is how to implement thread switching into these
user space threads. `td_thr_get_info()` does supply the stack pointer
and program counter at the point of user thread suspension, plus bounds
for the stack. There is, therefore, sufficient information for GDB to
print a backtrace. You obviously could not resume such a thread as when
it runs is under userspace control, but being able to see where it has
suspended and what it was doing up to the point of suspension would be
invaluable.
If somebody more knowledgeable of GDB internals could give me a few
pointers on how best to implement this, I would appreciate it.
Also, if you think that there is a way of going about this to make it
more likely that this patchset be accepted into GDB in the future, I
would be interested in hearing more.
My thanks in advance.
Niall
More information about the Gdb
mailing list