Date: Thu, 28 Feb 2002 18:36:09 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Bakul Shah <bakul@bitblocks.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Missing PT_READ_U Message-ID: <Pine.BSF.4.21.0202281833170.6492-100000@InterJet.elischer.org> In-Reply-To: <200203010226.VAA18006@warspite.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Feb 2002, 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? > > BTW, what is being added to allow debugging a post-KSE world > process? I'm planning on extending Ptrace. There will need to be a ptrace command to specify 1/ which thread you want future ptrace commands to control (e.g. single step), 2/ What you want the OTHER threads to do (e.g run as normal or stop) The READ_U should be replaced by a specific SIGSTATE command as you suggest I think. It only reads it right? > > -- 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?Pine.BSF.4.21.0202281833170.6492-100000>