lkml.org 
[lkml]   [2006]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: tracepoint maintainance models
From
Date
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 = &regA;
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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-10-06 07:37    [W:0.339 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site