Re: patches to actually use markers?

[Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>]

* Frank Ch. Eigler (fche@redhat.com) wrote:
> Hi -
> 
> On Fri, Nov 16, 2007 at 03:10:15PM -0500, Mathieu Desnoyers wrote:
> > [...]
> > > How would this syscall specific function get ebx or the string,
> > > without ebx (or regs) being passed as marker arguments?
> 
> > That's the idea : in the syscall specific function (not in
> > syscall_trace()), we add another marker that takes the syscall
> > specific arguments as parameter. I think we use the same approach
> > there.
> 
> I see.  Yes, per-systemcall markers would be welcome by our group, and
> ones not dependent on TIF_TRACE or whatnot even more so.  But were
> trying not to get too optimistic.
> 

I use per-systemcall markers for the principally useful systemcalls, but
I also instrument syscall_trace() to get all the other syscalls (new
ones, etc..).

I add my own TIF_KERNEL_TRACE, which is a thread flag enabled in each
and every thread when tracing is active. I think both have their own
advantage (complete information vs instrumentation of every, even less
important, system calls).

> 
> > What I was saying is that we can't extract the string from
> > syscall_trace() because we have no idea it is a string.
> 
> If "we" is a marker callback function that is given the system call
> number, it can be taught.  This is the sort of thing we do currently
> in systemtap script code based upon kprobes.
> 

Yeah.. but I fear that within the kernel it can become quickly very
ugly.

Mathieu

> - FChE

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68