This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: tracepoint maintainance models
- From: Steven Rostedt <rostedt at goodmis dot org>
- To: Vara Prasad <prasadav at us dot ibm dot com>
- Cc: Alan Cox <alan at lxorguk dot ukuu dot org dot uk>, "Frank Ch. Eigler" <fche at redhat dot com>, Ingo Molnar <mingo at elte dot hu>, Paul Mundt <lethal at linux-sh dot org>, Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>, linux-kernel <linux-kernel at vger dot kernel dot org>, Jes Sorensen <jes at sgi dot com>, Andrew Morton <akpm at osdl dot org>, Tom Zanussi <zanussi at us dot ibm dot com>, Richard J Moore <richardj_moore at uk dot ibm dot com>, Michel Dagenais <michel dot dagenais at polymtl dot ca>, Christoph Hellwig <hch at infradead dot org>, Greg Kroah-Hartman <gregkh at suse dot de>, Thomas Gleixner <tglx at linutronix dot de>, William Cohen <wcohen at redhat dot com>, "Martin J. Bligh" <mbligh at mbligh dot org>, systemtap <systemtap at sourceware dot org>
- Date: Fri, 06 Oct 2006 01:33:11 -0400
- Subject: Re: tracepoint maintainance models
- References: <20060917143623.GB15534@elte.hu> <20060917153633.GA29987@Krystal> <20060918000703.GA22752@elte.hu> <450DF28E.3050101@opersys.com> <20060918011352.GB30835@elte.hu> <20060918122527.GC3951@redhat.com> <20060918150231.GA8197@elte.hu> <1158594491.6069.125.camel@localhost.localdomain> <20060918152230.GA12631@elte.hu> <1158596341.6069.130.camel@localhost.localdomain> <20060918161526.GL3951@redhat.com> <1158598927.6069.141.camel@localhost.localdomain> <450EEF2E.3090302@us.ibm.com> <1158608981.6069.167.camel@localhost.localdomain> <450F0180.1040606@us.ibm.com>
Coming into this really late, and I'm still behind in reading this and
related threads, but I want to throw this idea out, and it's getting
late.
On Mon, 2006-09-18 at 13:28 -0700, Vara Prasad wrote:
> Alan Cox wrote:
>
> >
> >>This still doesn't solve the problem of compiler optimizing such that a
> >>variable i would like to read in my probe not being available at the
> >>probe point.
> >>
> >>
> >
> >Then what we really need by the sound of it is enough gcc smarts to do
> >something of the form
> >
> > .section "debugbits"
> >
> > .asciiz 'hook_sched'
> > .dword l1 # Address to probe
> > .word 1 # Argument count
> > .dword gcc_magic_whatregister("next"); [ reg num or memory ]
> > .dword gcc_magic_whataddress("next"); [ address if exists]
> >
> >
> >Can gcc do any of that for us today ?
> >
> >
> >
> No, gcc doesn't do that today.
>
>
---- cut here ----
#include <stdio.h>
#define MARK(label, var) \
asm ("debug_" #label ":\n" \
".section .data\n" \
#label "_" #var ": xor %0,%0\n" \
".previous" : : "r"(var))
static int func(int a)
{
int y;
int z;
y = a;
MARK(func, y);
z = y+2;
return z;
}
static void read_label(void)
{
extern unsigned short regA;
unsigned short *r = ®A;
char *regs[] = {
"A", "B", "C", "D", "DI", "BP", "SP", "CH"
};
int i;
extern unsigned short func_y;
extern unsigned long debug_func;
asm (".section .data\n"
"regA: xor %eax,%eax\n"
"regB: xor %ebx,%ebx\n"
"regC: xor %ecx,%ecx\n"
"regD: xor %edx,%edx\n"
"regDI: xor %edi,%edi\n"
"regBP: xor %ebp,%ebp\n"
"regSP: xor %esp,%esp\n"
".previous");
for (i=0; i < 7; i++) {
if (r[i] == func_y)
break;
}
if (i < 7)
printf("func y is in reg %s at %p\n",
regs[i],
&debug_func);
else
printf("func y not found!\n");
}
int main (int argc, char **argv)
{
int g;
g = func(argc);
read_label();
return g;
}
---- end cut ----
$ gcc -O2 -o mark mark.c
$ ./mark
func y is in reg B at 0x80483ce
Now the question is, isn't MARK() in this code a non intrusive marker?
So couldn't a kprobe be set at "debug_func" and we can find what
register "y" is without adding any overhead to the code being marked?
Obviously, this would need to be done special for each arch.
-- Steve