Hello, Michael Kelly, le jeu. 07 mai 2026 21:49:41 +0100, a ecrit: > On 05/05/2026 20:15, Samuel Thibault wrote: > > Michael Kelly, le mar. 05 mai 2026 20:11:29 +0100, a ecrit: > > > I have done that on occasion but I'm rather thinking of the case where a > > > gnumach thread is stuck awaiting an event which never happens. How can you > > > switch context to that thread and view its stack and so on? > > Ah, yes, in that case you can implement a libthread_db library that you > > give to gdb so it knows how to switch between threads in gnumach. > > Can you please elaborate on your vision for a libthread_db assisting with > gnumach stack traces? I'm sorry but I'm not seeing how it fits. > > I can see how thread_db operates for debugging a local user process and > indeed a remote user process with gdbserver if, for example, you had a > highly customised threads implementation. I cannot see how it might work > debugging an emulated kernel though. gdb will always use the gdbremote > protocol for this case and surely the detail of the gnumach threads has to > be supplied by the remote to the local gdb ? Does that not mean that the > customisation has to run either within the emulator (ie. qemu-system) or on > the target (guest) ?
? No, in gdb. 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. Samuel
