Date: Sat, 02 Mar 2002 00:13:31 -0800 From: Julian Elischer <julian@elischer.org> To: Bakul Shah <bakul@bitblocks.com> Cc: Peter Wemm <peter@wemm.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: Missing PT_READ_U Message-ID: <3C8089AB.892A6A86@elischer.org> References: <200203020722.CAA16024@tonnant.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bakul Shah wrote:
>
> > 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.
Just a quick comment Peter..
I was thinking we could stuff PT_READ_U back in for 4.x to keep UPS
going till we sort out the Ptrace API for 5.0 (which we need to do
soon because it's the next stumbling block.)
and then retrofit the new interface to 4.6(?) when we know what it
is rather than doing it twice..
I know that PT_READ_U is ugly and not really correct for rforked processes but
it probably can stay in 4.x for a little without doing any damage.
>
[...]
> - 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.
yes but if we changed the frame layout (which we could have done in
the kernel at any time) you lose.
> - 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!).
ummm one u page N threads.. that is why U page is dying..much
of the information init needs to be duplicated PER thread
(in the kernel)
> - 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]
Threads are transitory from the point of view of the kernel
you have just enough threads as you need to run the number of system
calls you have outstanding. if you are totally in user space (even on
N processors then theoretically you have no threads in the kernel so
the kernel has no threads assigned to you. (Actually it has N
held to one side reserved for you but theoretically they are only there
as a cache. On the other hand the kernel is not informed at all about how many
threads are running in the userland. and theoretically the userland thread
scheduler might switch through 100 userland threads without entering the kernel
once so teh kernel doesn't know if there are 100 or 1 threads defined in
userland. All it knows is that when it retunred to userland aftera syscall
blocked..
SOMETHING did another syscall.... :-)
> - 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.
The whole ptrace interfacestarts to fall apart here.
> - 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].
you'd have to nsert a breakpoint and CONDITIONALLY
allow the thread to run the new or old code according to which it was.
> - All this gets somewhat trickier (or impossible) to
> implement if you allow threads to run on multiple
> processors!
yep
> - 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
--
+------------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ julian@elischer.org +------>x USA \ a very strange
| ( OZ ) \___ ___ | country !
+- X_.---._/ presently in San Francisco \_/ \\
v
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?3C8089AB.892A6A86>