Hi - > [...] > - It _does not_ change the compiler optimisations. Like any similar mechanism, it does force the compiler to change its code generation, so one can't claim this too strongly. > [...] Comments are welcome, I'm still uneasy about the use of varargs. The current code now uses the formatting string as metadata to be matched (strcmp) between producer and consumer. A general tool that would use them would have to start parsing general printf directives. I believe they are not quite general enough either e.g. to describe a raw binary blob. I realize they serve a useful purpose in abbreviating what otherwise one might have to do (like that multiplicity of STAP_MARK_* type/arity permutations). But maybe there is a better way. Also, while regparm(0) may provide some comfort on x86, is there good reason to believe that the same trick works (and will continue to work) on non-x86 platforms to invoke a non-varargs callee with a varargs caller? - FChE
Attachment:
pgpevC4jqPI0Q.pgp
Description: PGP signature
- Follow-Ups:
- Re: [PATCH] Linux Kernel Markers 0.11 for 2.6.17
- From: Mathieu Desnoyers <[email protected]>
- Re: [PATCH] Linux Kernel Markers 0.11 for 2.6.17
- References:
- [PATCH] Linux Kernel Markers 0.11 for 2.6.17
- From: Mathieu Desnoyers <[email protected]>
- [PATCH] Linux Kernel Markers 0.11 for 2.6.17
- Prev by Date: Re: Smaller compressed kernel source tarballs?
- Next by Date: Re: GPLv3 Position Statement
- Previous by thread: [PATCH] Linux Kernel Markers 0.11 for 2.6.17
- Next by thread: Re: [PATCH] Linux Kernel Markers 0.11 for 2.6.17
- Index(es):