Samuel, On 08/05/2026 00:29, Samuel Thibault wrote:
I haven't looked at the details of thread_db, but the way I understand it is that thread_db can use the gdbserver protocol to ask qemu to access various parts of the memory, to get the information it needs. I.e. qemu wouldn't need any change, it is just a proxy to the gnumach memory. Gnumach itself doesn't need to do anything, it's qemu that accesses the memory. And it's thread_db which knows which variables should be read to get the threads list and their register statuses, etc.
I confess that I hadn't thought of the prospect of a custom thread_db making calls out to the remote debugger stub. I'm skeptical that is a realistic option given what I've seen from a casual study of the gdb source code.
The only thread_db that I've seen is the one in glibc that provides the details of the internals of pthreads to gdb via the thread_db function interface. I know that one is very different to what gnumach would need and being a user space library it gets the information via system calls into the Linux kernel running the target. My point being that it seems like it is expected that thread_db lives outside of gdb and is called by gdb. It does not make use of any gdb function but rather it provides necessary data to gdb.
There doesn't seem to be any relevant API exported by a gdb package installation. I can only see 1 header file installed and that is not connected to the issue under discussion. I'm supposing that a thread_db would need to use the same network/serial connection that gdb is already using to communicate with the remote debugger (qemu), so how would you find that connection and understand how to use it in code?
Yours confusedly, MIke.
