From owner-freebsd-hackers Fri Mar 1 21:43:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 8BC9337B400 for ; Fri, 1 Mar 2002 21:43:28 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020302054323.WXR1214.rwcrmhc54.attbi.com@peter3.wemm.org> for ; Sat, 2 Mar 2002 05:43:23 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g225hMs84146 for ; Fri, 1 Mar 2002 21:43:22 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 874273BAC; Fri, 1 Mar 2002 21:43:22 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Bakul Shah Cc: Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: Missing PT_READ_U In-Reply-To: <200203010226.VAA18006@warspite.cnchost.com> Date: Fri, 01 Mar 2002 21:43:22 -0800 From: Peter Wemm Message-Id: <20020302054322.874273BAC@overcee.wemm.org> 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 Bakul Shah wrote: > > 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. > > Yeah I saw that before sending out my query. This should've > waited until after KSE is in place. > > > 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? > > Signal handling state of the process being debugged (whether > ignored/caught etc). I haven't dug deeper into it so I > don't know why it wants that but it seems to be pretty deeply > wired in. > > > There are other ways to get all the information in question. > > There isn't. I don't think procfs will give me that either. > May be PT_{SET,GET}SIGSTATE should be added? As the culprit behind PT_READ_U's demise, I'm willing to dive in and help here if needed. Incidently, PT_READ_U didn't actually work for the case where the signal handlers were shared between rfork()'ed processes. Do you have any suggestions as to how PT_GET/SETSIGSTATE should look and feel? UPS's requirements seem pretty trivial (ie: return the handler for a given signal number), but that feels a bit minimalistic given that we have flags and a mask per signal as well. There is also the signal mask as well (masks are 128 bit). On the other hand, maybe we should just keep it simple for ptrace() since the API is so limited. > BTW, what is being added to allow debugging a post-KSE world > process? > > -- bakul > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message