* Frank Ch. Eigler ([email protected]) 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
Attachment:
signature.asc
Description: Digital signature
- Follow-Ups:
- Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- From: Mathieu Desnoyers <[email protected]>
- Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- References:
- [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- From: Mathieu Desnoyers <[email protected]>
- Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- From: [email protected] (Frank Ch. Eigler)
- Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- From: Mathieu Desnoyers <[email protected]>
- Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- From: "Frank Ch. Eigler" <[email protected]>
- Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- From: Mathieu Desnoyers <[email protected]>
- Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- From: "Frank Ch. Eigler" <[email protected]>
- Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- From: Karim Yaghmour <[email protected]>
- Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- From: "Frank Ch. Eigler" <[email protected]>
- [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- Prev by Date: sky2 eth device with Gigabyte 965P-S3 motherboard
- Next by Date: Re: [PATCH] Linux Kernel Markers
- Previous by thread: Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- Next by thread: Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
- Index(es):
![]() |