From owner-freebsd-current Wed May 12 0:42:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id A426D1529B for ; Wed, 12 May 1999 00:42:17 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.1/8.9.1) id RAA25621; Wed, 12 May 1999 17:53:25 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199905120753.RAA25621@cimlogic.com.au> Subject: Re: Debugging uthreads In-Reply-To: from Doug Rabson at "May 12, 1999 8:13:11 am" To: dfr@nlsystems.com (Doug Rabson) Date: Wed, 12 May 1999 17:53:24 +1000 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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". -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message