From owner-freebsd-current Wed May 12 1:48:56 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 2CF6D15C88 for ; Wed, 12 May 1999 01:48:48 -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 JAA04897; Wed, 12 May 1999 09:48:43 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 12 May 1999 09:48:43 +0100 (BST) From: Doug Rabson To: John Birrell Cc: current@freebsd.org Subject: Re: Debugging uthreads In-Reply-To: <199905120842.SAA25827@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: > > 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". That would work. I think I only need uniqueid, sig_saved, saved_sigcontext, saved_jmpbuf, state and nxt. If those guys were lumped up at the start of struct pthread (possibly in another struct so that gdb doesn't need to know sizeof(struct pthread)) and marked appropriately then the debugger interface would be quite stable. -- 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