> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
