Fork us on GitHub Follow us on Facebook Follow us on Twitter

Changes between Initial Version and Version 1 of Tracing


Ignore:
Timestamp:
2009-04-09T00:17:30Z (11 years ago)
Author:
trac
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Tracing

    v1 v1  
     1== Using the Syscall/IPC Tracer ==
     2
     3The 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.
     4
     5=== Command-line parameters ===
     6
     7To execute a program and trace it, type
     8{{{
     9trace <executable_path>
     10}}}
     11
     12on the command line. You can also specify which type of messages you want to see with a `+` and a combination of letters:
     13
     14 * `t` - Thread information (creation and termination of threads)
     15 * `s` - System-call layer
     16 * `i` - IPC layer (IPC calls with some decoding)
     17 * `p` - Application protocol messages (formatted to look like function calls and more extensively decoded)
     18
     19For example,
     20{{{
     21trace +tsip /app/tetris
     22}}}
     23will trace the Tetris application and it will output all possible messages (and there's a lot of them).
     24
     25Alternatively, to trace a running task, type
     26{{{
     27trace -t <task_id>
     28}}}
     29
     30=== Keyboard controls ===
     31
     32Press 'Q' anytime to quit the tracing application.
     33
     34=== Understanding the output ===
     35
     36A typical application-protocol message has the form:
     37{{{
     38<protocol>(<phone_id>).<method>(<arguments>).
     39}}}
     40
     41For example,
     42{{{
     43console(3).putchar('A').
     44}}}
     45
     46Here ''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).
     47
     48=== Notes ===
     49
     50 * 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!
     51
     52 * There are still bugs, the kernel can panic if the task being traced crashes.
     53
     54 * 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).