Date: Fri, 01 Mar 2002 23:22:47 -0800 From: Bakul Shah <bakul@bitblocks.com> To: Peter Wemm <peter@wemm.org> Cc: Julian Elischer <julian@elischer.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: Missing PT_READ_U Message-ID: <200203020722.CAA16024@tonnant.cnchost.com> In-Reply-To: Your message of "Fri, 01 Mar 2002 21:43:22 PST." <20020302054322.874273BAC@overcee.wemm.org>
index | next in thread | previous in thread | raw e-mail
> As the culprit behind PT_READ_U's demise, I'm willing to dive in
> and help here if needed.
Thanks but Julian sent me a patch for 4.5 that seems to work
with no changes in ups. Would be nice if PT_READ_U is put
back in 4.x.
Now that I think about it, ups will need to be fixed up since
the ability to write registers is lost with PT_WRITE_U gone
(have to use PT_SETREGS). If you want to put PT_WRITE_U back
in 4.5, I wouldn't complain;-)
> Incidently, PT_READ_U didn't actually work for the case where the
> signal handlers were shared between rfork()'ed processes.
Hmm... Probably neither does ups:-)
> 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).
I just copy struct sigacts in my code for this. There is no
PT_SETSIGSTATE (that would require a whole bunch of checking
for very little gain).
> On the other hand, maybe we should just keep it simple for ptrace() since
> the API is so limited.
There is time to think through API changes for 5.x. Reporting
signal state is a small part of this! Some random thoughts:
- should be able to get at additional registers (SSE etc. on x86).
- I'd just merge access to all registers in one register
space. This allows you to access any special or additional
registers intel/amd may throw at you (ditto for ppc)
without having to add more request codes. This is why
READ_U/WRITE_U were so useful.
- would be nice if the old interface of just returning one
word was put back even for registers. Typically you access
a very small number in a debugger (more typically never).
- May be for reading registers there is some value in a
read-all register interface but hardly ever for writing.
- Need a way to find out what threads exist and may be in
what state (if 5.x had a u-page, this would be part of
it!).
- Need PT_{ATTACH,DETACH,CONTINUE}_THREAD to deal with kernel
threads. Some sort of thread-id would be handy for this.
[But I don't know how you find a particular thread]
- On a breakpoint a number of threads may stop -- if you
allow other threads to proceed while the first thread at a
bkpt is stopped. Need an ability to report this as well as
continue/step any subset of these threads.
- Inserting debugging code that is run by a particular thread
and no one else can be tricky [ability to insert code is
one of the strengths of ups].
- All this gets somewhat trickier (or impossible) to
implement if you allow threads to run on multiple
processors!
- If all this is done, it should be not too hard to add
support (in a debugger) for debugging multi-process apps.
- Need to look at how multi-threaded apps are debugged on
other OSes and learn from that as well.
- Need to experiment before settling on an interface.
-- bakul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203020722.CAA16024>