lkml.org 
[lkml]   [2006]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
* Frank Ch. Eigler (fche@redhat.com) wrote:
> While varargs simplify some things, it sacrifices type-safety, in that
> a handler function would have to be varargs too. For the systemtap
> marker prototype, parametrized variants use scores of (automatically
> generated) macros, with different arity/type permutations, each
> self-describing and type-safe.
>
The format string could be used to provide some kind of type safety : the
compiler will check that arguments match the format string provided. From there,
a simple script can parse the format string and generate a function prototype
accordingly. Correct me if I am wrong, but I think that if the called function
has the exact same parameter layout as the varargs caller stack, the function
call should work (without the called function having a variable arguments list).

> Regarding a marker variant that would require kprobes (inserting a
> labelled NOP or few), it may be an appropriate choice where dormant
> marker overhead must be minimal and robust parameter passing is less
> important.
>

I even came with the following idea :

Instead of using a test + conditional predicted branch, we could jump to an
address locate just after the probe.

jmp to over_symbol address
call_symbol
call function pointer
over_symbol

This way, we could have portable :
- direct inconditional jump to an address following the marked site when
disabled
- Enable stack setup and function call by setting the function pointer and
changing the jmp target to be "call_symbol"
- Enable "direct jump to arbitrary assembly" by setting the jump target to
arbitrary code, where this code can end by jumping to over_symbol.

The generated binary on x86 looks like :

10: a1 24 00 00 00 mov 0x24,%eax
15: ff e0 jmp *%eax
17: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp)
1e: 00
1f: c7 04 24 00 00 00 00 movl $0x0,(%esp)
26: ff 15 1c 00 00 00 call *0x1c

With those symbols :

f8875c08 b __mark_subsys_mark1_call [test_mark] (function pointer)
f8875620 d __mark_subsys_mark1_jump_call [test_mark]
f8875624 d __mark_subsys_mark1_jump_over [test_mark]

The macro doing that :

#define MARK_CALL(name, format, args...) \
do {\
__label__ call_label, over_label; \
static void *__mark_##name##_jump_over \
asm ("__mark_"#name"_jump_over") = \
&&over_label; \
static void *__mark_##name##_jump_call \
asm ("__mark_"#name"_jump_call") \
__attribute__((unused)) = \
&&call_label; \
static void (*__mark_##name##_call)(const char *fmt, ...) \
asm ("__mark_"#name"_call") = __mark_empty_function; \
goto *__mark_##name##_jump_over; \
call_label: \
(void) (__mark_##name##_call(format, ## args)); \
over_label: \
do {} while(0); \
} while(0)

A problem I saw in your approach was that there was no way to remove the
function pointer without taking the risk to break everything.

The solution I came up with is to set the function to an empty
__mark_empty_function when disabled, and set another function pointer to enable
it.

Any thoughts ?

Mathieu


OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2006-09-20 18:41    [W:0.068 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site