On Wed, 12 May 1999, John Birrell wrote: > Doug Rabson wrote: > > I didn't want to use the address since it might cause confusion if a > > thread was freed and then the memory was re-allocated to create a new > > thread. > > Good reason. > > > I thought about the versioning but I don't think it will be a problem in > > practice since both uthread and gdb will generally be built by a single > > 'make world'. > > But libc_r isn't linked into anything during a 'make world'. It is only > linked to 3rd party applications. So, although libc_r and gdb are in > sync at the end of a 'make world', any statically linked applications > will be out-of-sync (if an internal change has been made to libc_r). > I'm not sure there is an easy solution to this.
Other gdb thread debugging systems tend to export a set of variables from the thread library which describe the important offsets in the thread structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset etc. If you think there will be a real problem, I could do this I guess. -- 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
