From owner-freebsd-current Wed May 12 3:36:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 74B4715270 for ; Wed, 12 May 1999 03:36:10 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id GAA10411; Wed, 12 May 1999 06:35:31 -0400 (EDT) Date: Wed, 12 May 1999 06:35:31 -0400 (EDT) From: Daniel Eischen Message-Id: <199905121035.GAA10411@pcnet1.pcnet.com> To: eischen@vigrid.com, jb@cimlogic.com.au Subject: Re: Debugging uthreads Cc: current@FreeBSD.ORG, dfr@nlsystems.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Birrell wrote: > Daniel Eischen wrote: > > Why don't we make a libc_r_db and provide the necessary interfaces to > > gdb from that instead of having gdb know about uthread internals? > > It would still mean that gdb would be linked to the uthread internals > which may not match the version of libc_r that the 3rd party program > was linked against. OK, but it still seems more appropriate to have uthread debugging internals known somewhere other than in GDB. It seems more obvious to have to modify libc_r_db when libc_r changes than to know to update the gdb sources. If threads had versioning information as well as trying to set certain attributes in stone, then libc_r_db could be made to be backwards compatible with older thread libraries. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message