This is the mail archive of the
mailing list for the systemtap project.
[RFC] Proposal of marker implementation
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: SystemTAP <systemtap at sources dot redhat dot com>
- Cc: Yumiko Sugita <yumiko dot sugita dot yf at hitachi dot com>, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>
- Date: Wed, 09 Aug 2006 14:33:11 +0900
- Subject: [RFC] Proposal of marker implementation
- Organization: Systems Development Lab., Hitachi, Ltd., Japan
I'd like to suggest my marker idea which I spoke in OLS.
My idea is based on the "section" of elf binary and the djprobe.
Here is the concept code on i386 architecture.
#define __MARKER_NOP(name) \
asm volatile ("771:\n\t" ASM_NOP6 "\n772:\n" \
".section .markers,\"a\"\n" \
" .align 4\n" \
" .long 771b\n" /* label */ \
" .byte 772b-771b\n" /* length */ \
" .string \"" #name "\"\n" /* name */ \
#define MARKER(n) __MARKER_NOP(n)
This code comes from the "alternative" macros in the asm/alternative.h.
We can extract this marker's information by using the readelf command as below;
$ readelf -x ".markers" marker.ko
Hex dump of section '.markers':
0x00000000 00000010 00000074 696e6906 00000003 .....init.......
0x00000010 0074 69786506 .exit.
This section contains two markers;
mark address = 00000003
mark length = 06
marker name = 696e697400 = "init"
mark address = 00000010
mark length = 06
marker name = 6578697400 = "exit"
So, we can check it by using the "objdump" command.
$ objdump -d marker.ko
marker.ko: file format elf32-i386
Disassembly of section .text:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 8d b6 00 00 00 00 lea 0x0(%esi),%esi <--- here is "init" marker
9: 31 c0 xor %eax,%eax
b: 5d pop %ebp
c: c3 ret
d: 55 push %ebp
e: 89 e5 mov %esp,%ebp
10: 8d b6 00 00 00 00 lea 0x0(%esi),%esi <--- here is "exit" marker
16: 5d pop %ebp
17: c3 ret
Each marker has 6bytes NOP. I think we can replace it with a jump code
safely by using djprobe. Note: we can not replace it with a "call" code
because it will break some caller-save registers.
I think this marker has many advantages.
- Minimal overhead (don't touch any memory if it is deactivated)
- Multiple markers can have the same name (we can activate those at once)
- There are no additional marking symbols in the kernel.
- Easily extensible format (we can add some additional information in the section)
Also has some disadvantages.
- Architecture dependency (but the "section" itself doesn't depend on the arch)
- Need djprobe for safety (we can use kprobes until it goes fine)
Any comments are welcome.
By the way, flight recorder patches and STPtracer (re-implementation
of LKST on SystemTap) package are now under prior examination by
So, I'll send it in the week after next.
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory