Date: Thu, 28 Feb 2002 18:26:09 -0800 From: Bakul Shah <bakul@bitblocks.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Missing PT_READ_U Message-ID: <200203010226.VAA18006@warspite.cnchost.com> In-Reply-To: Your message of "Thu, 28 Feb 2002 16:13:05 PST." <Pine.BSF.4.21.0202281610190.6492-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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?
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203010226.VAA18006>