On Wed, 12 May 1999, Daniel Eischen wrote: > John Birrell wrote: > > Daniel Eischen wrote: > > > Why don't we make a libc_r_db and provide the necessary interfaces to > > > gdb from that instead of having gdb know about uthread internals? > > > > It would still mean that gdb would be linked to the uthread internals > > which may not match the version of libc_r that the 3rd party program > > was linked against. > > OK, but it still seems more appropriate to have uthread debugging > internals known somewhere other than in GDB. It seems more obvious > to have to modify libc_r_db when libc_r changes than to know to > update the gdb sources. > > If threads had versioning information as well as trying to set > certain attributes in stone, then libc_r_db could be made to > be backwards compatible with older thread libraries.
GDB's needs are rather simple. It needs to know the current thread, be able to enumerate all threads, and access the saved register set of a non-current thread. I don't want to over-engineer the thing given that writing the gdb side of things was actually pretty simple. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
