Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17

From: Mathieu Desnoyers
Date: Wed Sep 20 2006 - 10:57:59 EST


Hi Frank,

Here is a revised proposal (just the marker.h). Do you have ideas on how we can
export the function symbol ? (is it necessary ?)

Any thoughts ?

----- BEGIN -----


#include <asm/marker.h>

#ifdef CONFIG_MARK_SYMBOL
#define MARK_SYM(name) \
do { \
__asm__ ( "__mark_kprobe_" #name ":" ); \
} while(0)
#else
#define MARK_SYM(name)
#endif


#ifdef CONFIG_MARK_CALL
#define MARK_CALL(name, format, args...) \
do {\
static void (*__mark_call_##name##_)(const char *fmt, ...) \
asm ("__mark_call_"#name); \
if (unlikely (__mark_call_##name##_)) \
(void) (__mark_call_##name##_(format, ## args)); \
} while(0)
#else
#define MARK_CALL(name, format, args...)
#endif

#define MARK(name, format, args...) \
do { \
__mark_check_format(format, ## args); \
MARK_SYM(name); \
MARK_CALL(name, format, ## args); \
} while(0)

static inline __attribute__ ((format (printf, 1, 2)))
void __mark_check_format(const char *fmt, ...)
{ }


---- END ----



* Mathieu Desnoyers (compudj@xxxxxxxxxxxxxxxxxx) wrote:
> * Frank Ch. Eigler (fche@xxxxxxxxxx) wrote:
> > Hi -
> >
> > > > [...] For the static part of the instrumentation, a
> > > > marker that could be hooked up to either type of probing system was
> > > > desirable, which implies some sort of run-time changeability.
> > >
> > > Ok. So if I get what you're saying here, you'd like to be able to
> > > overload a marker?
> >
> > Sort of. Remember, we discussed markers as *marking* places and
> > things, with the intent that they be decoupled from the actual
> > *action* that is taken when the marker is hit.
> >
> > > Can you suggest a macro that can do what you'd like. [...]
> >
> > Compare the kind of marker I showed at OLS and presently supported by
> > systemtap. Its unparametrized version looks like this:
> >
> > #define STAP_MARK(name) do { \
> > static void (*__mark_##name##_)(); \
> > if (unlikely (__mark_##name##_)) \
> > (void) (__mark_##name##_()); \
> > } while (0)
> >
> > A tracing/probing tool would hook up to a particular and specific
> > marker at run time by locating the __mark_NAME static variable (a
> > function pointer) in the data segment, for example using the ordinary
> > symbol table, and swapping into it the address of a compatible
> > back-end handler function. When a particular tracing/probing session
> > ends, the function pointer is reset to null.
> >
> > Note that this technique:
> >
> > - operates at run time
> > - is portable
> > - in its parametrized variants, is type-safe
> > - does not require any future technology
> > - does impose some overhead even when a marker is not active
> >
> >
> Hi Frank,
>
> Yes, I think there is much to gain to switch from the 5 nops "jumpprobe" to
> this scheme. In its parametrized variant, the jump will probably jump over a
> stack setup and function call. Do you think I should simply switch from the
> 5 nops marker to this technique ? I guess the performance impact of a
> predicted branch will be similar to 5 nops anyway...
>
> The clear advantage I see in the parametrized variant is that the parameters
> will be ready for the called function : it makes it trivial to access any
> variable from the traced function.
>
> Mathieu
>
>
> OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
> Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68


OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68

Attachment: signature.asc
Description: Digital signature