From owner-freebsd-current  Wed May 12  3:17:27 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 1591D1506E
	for <current@FreeBSD.ORG>; Wed, 12 May 1999 03:17:25 -0700 (PDT)
	(envelope-from eischen@vigrid.com)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id GAA08837;
	Wed, 12 May 1999 06:16:46 -0400 (EDT)
Date: Wed, 12 May 1999 06:16:46 -0400 (EDT)
From: Daniel Eischen <eischen@vigrid.com>
Message-Id: <199905121016.GAA08837@pcnet1.pcnet.com>
To: dfr@nlsystems.com, jb@cimlogic.com.au
Subject: Re: Debugging uthreads
Cc: current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

John Birrell wrote:
> Doug Rabson wrote:
> > 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.
>
> Maybe we should just isolate the things that gdb is allowed to look at
> and document them as "cast in stone".

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?

Dan Eischen
eischen@vigrid.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message