|Version 1 (modified by 15 years ago) ( diff ),|
Using the Syscall/IPC Tracer
The tracer application (/app/trace) is meant to give you a rough idea about what your application is doing by printing the system calls it is making. However, since HelenOS is a microkernel system, the system calls are not all that interesting, since they are mostly just IPC calls. For this reason, the tracer tries to analyze communication on higher layers to a certain extent, i.e. the IPC communication and (in a very primitive way) the application protocols.
To execute a program and trace it, type
on the command line. You can also specify which type of messages you want to see with a
+ and a combination of letters:
t- Thread information (creation and termination of threads)
s- System-call layer
i- IPC layer (IPC calls with some decoding)
p- Application protocol messages (formatted to look like function calls and more extensively decoded)
trace +tsip /app/tetris
will trace the Tetris application and it will output all possible messages (and there's a lot of them).
Alternatively, to trace a running task, type
trace -t <task_id>
Press 'Q' anytime to quit the tracing application.
Understanding the output
A typical application-protocol message has the form:
Here phone_id is the ID of the phone on which the request is being made. The protocol field is the name of the protocol that the tracer believes is being used on that phone. (This is normally detected by spying on the communication with the naming service.) The method is a textual representation of the IPC method number (for that protocol). The period (
.) at the end of the line denotes that the request returns no value (and thus the response will not be displayed).
- Decoding tables for application protocols are currently very incomplete. Unrecognized calls are not printed at all at the protocol level, you must display IPC-level messages (
+i) to see them!
- There are still bugs, the kernel can panic if the task being traced crashes.
- The tracer actually kicks in a little while before the program starts (i.e. at the end of the loader). Thus the first few messages you see concern the loader, rather than the C library startup code. (The loader closes its console connection and answers the RUN call, then it jumps to the entry point of the program).