From owner-freebsd-current Wed May 12 1:15:49 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 C9F1514C12 for ; Wed, 12 May 1999 01:15:44 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.1/8.9.1) id SAA25753; Wed, 12 May 1999 18:27:04 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199905120827.SAA25753@cimlogic.com.au> Subject: Re: Debugging uthreads In-Reply-To: from Doug Rabson at "May 12, 1999 9: 8:45 am" To: dfr@nlsystems.com (Doug Rabson) Date: Wed, 12 May 1999 18:27:03 +1000 (EST) Cc: jb@cimlogic.com.au, 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 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. -- 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