Tracing with Genode

[Josef Söntgen]

Hello Torsten,


* Torsten Frenzel <frenzel at ...28...> [2015-05-27 10:53:59 +0200]:
> I'm working with the 15.02 release and found two examples of policy modules,
> called null and rpc_name. Are there other examples in branches of the repo
> on how to implement a custom policy module. In general what are the
> restrictions, when implementing a policy module?

Currently, these two examples are the only ones. Since a policy is
basically a stand-alone blob that may be attached at any adress in the
address space of a thread it may not contain any relocations or
references to the “outer world” and therefore has to provide all that
it needs by itself. A while back I started to write a more detailed
example (see my 'trace_terminal' branch [1]) including some convenience
classes for the trace framework but did not finish it for various
reasons.


> Is it possible to extract more specific information for a certain event,
> for example, the name of the destination, that was called. Furthermore,
> the policy modules for Rpc_call and Rpc_returned events have access to a
> data structure of type Msgbuf_base. As far as I understood the message
> buffer contains the arch-depended marshalled data. Is there a generic
> mechanism to interpret these data in a meaningful way inside policy module
> or the trace monitor?

The interface is quite generic in this regard and does not provide any
specific information. I am afraid there is also no utility which helps
you in parsing the data in the message buffer. For now, you have to do
this manually.


> It would be helpful to accurately timestamp every recorded event with a
> value of a real time clock. But that would require access to service that
> provides such an information. Again, I cannot see how to get access to such
> a service from inside the policy module, because it hasn't access to the
> Genode runtime environment. Maybe the correct approach would be to use a fast
> timestamp function inside the policy module and later calculate the real time
> value in the trace monitor?

Until now, we have always used either the TSC on x86 or the performance
counters on ARM to collect a timestamp (it is implemented for all
platforms accordingly in the 'trace/timestamp.h' header. Combing that
with information provided by a real time clock is normally done by the
trace monitor.


> Is it possible to disable/enable specific types of events (, may be using the
> Trace::Control data structure)?

Well, you can selectively enable or disable specfic types through the
trace policy module but there is no explicit API for that.


> Is there a mechanism that the trace monitor is notified, when a trace-buffer
> is full or has reached a threshold?

No.


> When I played around with the test_trace program, I noticed that loading more
> than policy module into core fails. After some investigations I found that the
> slab_size for the constructed allocator used in the Policy_registry class for
> Trace::Policy objects is only 4 bytes, but Trace::Policy objects have a larger
> size of 26 bytes. When I changed the constructor in the session component as
> shown below everything works fine. So for some reason the compiler selects the
> Avl_node_base::Policy class in the template.
> 
> diff -r ./base/src/core/include/trace/session_component.h . 
> 40,41c40,41
> < 		Tslab<Trace::Policy, 4096>  _policies_slab;
> ---
> > 		Tslab<Policy, 4096>  _policies_slab;

Nice catch! Johannes reported this problem [2] some time ago but we
did not come around to tackle it. It would be nice if you could note
your finding in the issue on github. Thanks in advance.


Regards
Josef

[1] https://github.com/cnuke/genode/commits/trace_terminal
[2] https://github.com/genodelabs/genode/issues/1508