This is the mail archive of the
mailing list for the systemtap project.
Re: patches to actually use markers?
* Frank Ch. Eigler (firstname.lastname@example.org) 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
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
> - FChE
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68