Date: Wed, 12 May 1999 09:28:00 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: John Birrell <jb@cimlogic.com.au> Cc: current@freebsd.org Subject: Re: Debugging uthreads Message-ID: <Pine.BSF.4.05.9905120925220.385-100000@herring.nlsystems.com> In-Reply-To: <199905120827.SAA25753@cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905120925220.385-100000>