Chris Moller wrote:
Phil Muldoon wrote:
Thanks for the description Chris. From an ntrace client
implementation "point of view", non-ordered replies to asynchronous
requests present an ordering conundrum in the client - especially as
it scales to many many inferiors.
I tend to think of the asynch stuff not as "replies" but as
"responses," of which there are three types. The most common (this is
from utracer--things may change) is the response to an operational
change like a "quiesce" command. The command itself is non-blocking
and returns immediately to the caller, and the kernel action is
immediate--setting the QUIESCE bit in the utrace engine--but the task
won't actually quiesce until it's in, to use Roland's description, a
"safe" state. At that point the engine issues a report_quiesce()
which results in an asynchronous response, on the response thread, to
the debugger.
Sounds sensible. Perhaps from the old utracer, or this new interface, do
you have a running api? It doesn't have to be finished, or even set in
stone. Just an idea. I'm guessing your answer will be, look in the code
when I get the repository up ;) But it would be interesting to see this
in the making. The Quiesce command above for example. I'm pondering what
happens if a task dies before it reached a safe state to be quiesced.
Over on Frysk we are taking a good, long look at our goals and one of
those is interfacing to the new user-land api of utrace. Is there a
moral equivalent available yet to the ptrace like control enums that one
used to use with ptrace?
A second kind of response is less direct. For example, the debugger
can issue a command to report the arrival of specified signals or
entry into (or exit from, or both) specified syscalls. Again, the
response to the command is non-blocking, but there obviously won't be
a response-thread response unless and until that a qualifying signal
arrives or a qualifying syscall is actually entered or exited.
Finally, there are truly immediate responses. For example, a request
for the contents of one or more registers (utracer allowed the app to
request a range of regs, e.g., all the GPRs, down to and including a
single specified reg) will be responded to immediately, on the control
thread, with that information. (Assuming the task is quiesced; an
error condition will be raised otherwise.)
I'm not sure I hold truck with responses appearing on a control thread
and the response thread. It would require a bit of knowledge beyond the
api (I'm calling the interface an api, for want of a better term).
What's preventing scheduling a reply to an immediate response on the
response thread over the control thread?
All response-thread responses are structured and contain an enum
specifying the nature of the response--"here's a syscall entry of the
kind you asked for"--as well as the PID of the task that generated the
response. If it would be useful, I suppose some sort of sequence
number could be returned as well, or maybe an application-supplied
transaction identification number could be returned. That might help
in dealing with out-of-order problems.
When the the code is up somewhere, and we look at the api, we could
revist this a bit later perhaps.
Regards
Phil
