Re: 64 bit gnumach KDB stack traces

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.