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

[Mathieu Desnoyers <compudj at krystal dot dyndns dot org>]

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@krystal.dyndns.org) wrote:
> * Frank Ch. Eigler (fche@redhat.com) 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