Date: Fri, 01 Mar 2002 21:43:22 -0800 From: Peter Wemm <peter@wemm.org> To: Bakul Shah <bakul@bitblocks.com> Cc: Julian Elischer <julian@elischer.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: Missing PT_READ_U Message-ID: <20020302054322.874273BAC@overcee.wemm.org> In-Reply-To: <200203010226.VAA18006@warspite.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020302054322.874273BAC>