From owner-freebsd-hackers Thu Feb 28 16:20:19 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 1E66A37B400 for ; Thu, 28 Feb 2002 16:20:17 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020301002016.JPXJ2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 1 Mar 2002 00:20:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA08405; Thu, 28 Feb 2002 16:13:07 -0800 (PST) Date: Thu, 28 Feb 2002 16:13:05 -0800 (PST) From: Julian Elischer To: Bakul Shah Cc: freebsd-hackers@freebsd.org Subject: Re: Missing PT_READ_U In-Reply-To: <200202280736.CAA29627@wellington.cnchost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 27 Feb 2002, Bakul Shah wrote: > Now that ptrace(PT_READ_U, ...) has been excised how does one > find out what actions are registered for various signals? > The ups debugger needs this. Please see > /usr/ports/devel/ups-debug/work/ups-3.35-beta13/ups/ao_pt_uarea.c:632 > > Thanks! > Here's the commit message in question: Revision 1.69 / (download) - annotate - [select for diffs], Wed Aug 8 05:25:07 2001 UTC (6 months, 3 weeks ago) by peter Branch: MAIN CVS Tags: KSE_PRE_MILESTONE_2 Changes since 1.68: +1 -44 lines Diff to previous 1.68 (colored) Zap 'ptrace(PT_READ_U, ...)' and 'ptrace(PT_WRITE_U, ...)' since they are a really nasty interface that should have been killed long ago when 'ptrace(PT_[SG]ETREGS' etc came along. The entity that they operate on (struct user) will not be around much longer since it is part-per-process and part-per-thread in a post-KSE world. gdb does not actually use this except for the obscure 'info udot' command which does a hexdump of as much of the child's 'struct user' as it can get. It carries its own #defines so it doesn't break compiles. this pretty much says it.. the uarea is pretty much a shadow of its former self The fields have been scattered across two structures. What is ups trying to find out? There are other ways to get all the information in question. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message