Date: Thu, 28 Feb 2002 16:13:05 -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.0202281610190.6492-100000@InterJet.elischer.org> In-Reply-To: <200202280736.CAA29627@wellington.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0202281610190.6492-100000>