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

[Mathieu Desnoyers]

* Frank Ch. Eigler (fche@xxxxxxxxxx) 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

Attachment: signature.asc
Description: Digital signature