Folks, Apologies if this is the wrong mailing list to ask a question regarding GDBServer / RSP and a potential bug. I have been working on new extensibility API surfaces for the Windows platform debuggers that allow folks to write plug-ins that can connect those debugging tools to a variety of new targets including ones that are not Windows based. We've had the ability to do this for post-mortem targets for some time and are, of late, working to expand that API surface to various forms of live targets. As proof of concept for the API surface, I've been experimenting with writing such a plug-in to connect to the standard user mode GDBServer for Linux. A few things I'll note: 1. When thread events are enabled on the server via a QThreadEvents:1, GDBServer immediately crashes on any thread exit in "resume" on a NULL deref of current_thread. 1. I tried a quick patch here (adding "cs.last_status.kind() != TARGET_WAITKIND_THREAD_EXITED") to the set of conditions that won't set "current_thread->last_status" and the wXXX thread exit packets get sent; however, regardless of whether the target is in non-stop mode or not, the process is STILL RUNNING at the time the server sends the "wXXX" packet. Am I missing something with GDBServer and thread events or is this just not well supported...? The process seems to be stopped at the point that a thread creation event gets sent... but not for a thread exit... I assume that's a bug somewhere in GDBServer...? Or am I misreading the docs at https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html...? Is there some alternate means by which thread create/exit notifications come...? Sincerely, Bill Messmer wmessmer@microsoft.com