This is the mail archive of the
mailing list for the systemtap project.
Re: [RFC] Proposal of marker implementation
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Nicholas Miell <nmiell at gmail dot com>
- Cc: fche at redhat dot com, yumiko dot sugita dot yf at hitachi dot com, soshima at redhat dot com, haoki at redhat dot com, SystemTAP <systemtap at sources dot redhat dot com>
- Date: Mon, 21 Aug 2006 10:58:27 +0900
- Subject: Re: [RFC] Proposal of marker implementation
- Organization: Systems Development Lab., Hitachi, Ltd., Japan
- References: <44D97397.email@example.com> <firstname.lastname@example.org>
Nicholas Miell wrote:
> On Wed, 09 Aug 2006 14:33:11 +0900, Masami Hiramatsu wrote:
>> 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.
> You can use a call instruction if the function you're calling is an
> assembly stub which saves caller-saved registers and then calls a C
> function (passing the saved return address as a parameter so the probe
> point can be located).
It's a nice idea, if the systemtap can treat a modified pt_regs structure.
My jump based method can provide the pt_regs structure like as the kprobe.
Thus, the systemtap can treat it transparently.
But, once we use a call instruction, it changes the contents of the stack.
It means that a special handler is needed for the marker.
Anyway, I think that is a considerable and useful idea.
> Alternately, you could do a normal C function call and then replace
> the call instruction with NOPs as a post-processing step. This method lets
> the C compiler save the caller-saved registers for you, and you can easily
> pass parameters.
Exactly. But, in this method, we have to pay some costs to save caller-saved
registers if those markers are disabled.
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory