Notes from the systemtap BOF

[Mathieu Desnoyers]

* Karim Yaghmour (karim@opersys.com) wrote:
> 
> It looks like the only way to safely use jmps instead of int3s is to
> actually insert nops in the region you intend to insert jmps ... which
> is very much a case for markers.
> 

In fact, even using nops won't guarantee that an interrupt did not happen in the
middle of the nops.

> > Or, should we consider the idea that we use the simple space that 
> > contains just 5 nops(*) ?
> > 
> > (*) like below
> > #define __JMP_POINT(tname) {asm volatile( ".global" #name "; "\
> >                                          #name ":nop;nop;nop;nop;nop;");}
> > #define JMP_POINT(name) __JMP_POINT(name##_tag)
> 
> 
> hmm... yes, this is what makers are about.
> 
> Mathieu: maybe you could post the preliminary bit of code you had written
> during OLS for markers?
> 

Sure, here it is.

This code is just composed of ideas about how we could derive a unique string
from a marker definition.

I also tried to figure out how to save this string in a symbol, but it looks
like we need to declare something outside the scope of the function
(MAGIC_TRACE_SYM).

I would really like to be able to do both inside the function scope, but I can't
figure out how.

Well, the basic idea of the MAGIC_TRACE_SYM is to assign an unique address
(pointed to by a symbol) matching the unique string ID, which could then be used
as an event identifier.

What could be done is to use the pointer to the string describing the
event as a parameter to the trace_##event(...) function. We could then register
the event when the trace point is hit for the first time. Afterward, we would
have to use a hash table to keep trace of the registered (address, string)
tuples. This adds a little bit of code to the critial logging path, which I
would like to avoid. It will also cause problem for module unloading, which may
lead to having the same address used for a different event string (there is no
"unregistration" possible).


Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltt-macro.c
Type: text/x-csrc
Size: 1546 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20050727/51ddc34f/attachment.bin>