On Thu, 18 Sep 2003, Brad Knowles wrote: > At 4:47 PM -0700 2003/09/17, Doug White wrote: > > > This came up at the developer summit. We do need to upgrade/make > > significant changes to gdb for it to understand threaded debugging. The > > panics might be interesting as it might be tickling other issues, but > > before we can really debug threaded apps we need a new gdb. The panics had nothing to do with KSE, gdb, or threading and were recently fixed. > Do we need a rewritten gdb, or can we have both the current gdb > and a new tgdb for debugging the threaded stuff? It is relatively easy to modify the existing threading support in gdb so that we can at least view the current threads. Other kernel support would be needed to attach to threads in other KSEs and retrieve register sets for threads blocked in the kernel. Libthr has similar problems. > The latter approach seems to be something that would be a lot > easier to integrate without risk of breaking anything currently > existing, and tgdb could even be done as a port until such time as > it's fully ready to take over from the built-in gdb in the system. FreeBSD's threading support is not presently in stock GDB anyways; it's in gnu/usr.bin/binutils/gdb/freebsd-uthread.c, not in contrib/gdb/... I don't see the need for a separate port. The two problems are: o adding kernel support to attach to threads in different KSEs and fetching register sets from threads blocked in the kernel o making gdb understand not only libc_r, but also libthr and libpthread, and how to determine which library it is debugging. -- Dan EischenReceived on Thu Sep 18 2003 - 12:43:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:22 UTC