For information about launching fidlcat: fidlcat.
This file only renders correctly within fuchsia.dev. If you don't see the examples, navigate to https://fuchsia.dev/fuchsia-src/development/fidl_inspecting/fidlcat_usage
The default display for fidlcat is:
We have the following information:
echo_client_cpp_synchronous: the name of the application which has generated this display.
180768: the process koid.
180781: the thread koid.
zx_channel_call: the name of the intercepted/displayed system call.
all the basic input parameters of the system call (here handle and options).
For each one, we have:
The name of the parameter in black.
The type of the parameter in green.
The value of the parameter (the color depends on the parameter type).
all the complex input parameters. Here we display a FIDL message. This is a request which is sent by our application.
The display stops here. It will resume when the system call returns (sometimes it can be a very long time). For one thread, there will be no other display between the input arguments and the returned value. However, another thread display may be interleaved. When the system call returns, we display:
The returned value (-> ZX_OK)
The basic output parameters (there is no basic output parameters in this example).
The complex output parameters. Here we display a FIDL message. This is the response we received to the request we sent.
For zx_channel_read we can have this display:
But, if there is an error, we can have:
Or:
In this last case, even if the system call fails, we have some valid output parameters. actual_bytes and actual_handles give the minimal values which should have been used to call zx_channel_read.
By default, we only display the process information on the first line.
Eventually, we also display the process information before the returned value if a system call from another thread has been displayed between the call and the returned value:
Using the flag --with-process-info, we can display the process information on each line:
This is very useful if we want to do a grep on the output (for example, to only select one thread).
Most of the time we want to link several messages to be able to understand what our program is doing.
In this example:
We first create a channel. The two handles 0243b493 and 0163b42b are linked. That means that a write on one handle will result on a read on the other handle.
We use handle 0163b42b in the Directory.Open message. That means that the associated handle (0243b493) is the handle which controls the directory we just opened.
When we receive Node.OnOpen on 0243b493 we know that it's a response to our Directory.Open. We also used the handle to call Node.Close.
