From owner-freebsd-current Wed May 12 1: 9:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id E2C4B14EEF for ; Wed, 12 May 1999 01:08:57 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA62503; Wed, 12 May 1999 09:08:45 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 12 May 1999 09:08:45 +0100 (BST) From: Doug Rabson To: John Birrell Cc: current@freebsd.org Subject: Re: Debugging uthreads In-Reply-To: <199905120753.RAA25621@cimlogic.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 12 May 1999, John Birrell wrote: > Doug Rabson wrote: > > I've put an initial version of my hack for debugging FreeBSD user threads > > with gdb up on http://www.freebsd.org/~dfr/uthread.diff. Comments would be > > appreciated. > > Is the uniqueid really necessary when the address of the thread structure > is already unique within the process address space? After all, that's > what the thread ID is (a pointer to the malloc'd memory). > > I have the feeling that there needs to be some way to discover if the > version of gdb being used is compatible with the version of libc_r that > the program is linked against. Otherwise we end up with a similar > problem to the all too familiar "struct proc size mismatch". 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. 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'. -- 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