This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patches to actually use markers?

* David Smith ( wrote:
> David Smith wrote:
> > Mathieu Desnoyers wrote:
> >> * David Smith ( wrote:
> >>> Mathieu,
> >>>
> >>> Now that the markers facility itself has made it in the kernel, do
> >>> you have plans on trying to send patches that actually use markers to
> >>> lkml?
> >>>
> >>> For systemtap's use, we'd like to get some actual markers in the
> >>> upstream kernel.  Off the top of my head, we might start with adding
> >>> markers to system calls (sys_*) that contain the system call's
> >>> argument(s).
> >>>
> >>
> >> Hi David,
> >>
> >> Yes, we have something similar in LTTng, we instrument many widely used
> >> system calls to get the detailed arguments.
> ...
> >> It's a good thing that we start having a discussion about these marker
> >> sites at this point.
> >>
> >> Mathieu
> I've been looking at your system call tracing patches.  (I've tried
> running lttv itself without much luck, but it doesn't really matter for
> the sake of this discussion.)
> I like the way you use the existing system call tracing points.  So
> we're on the same page, here are the markers I'm seeing in
> arch/x86/kernel/ptrace32.c after applying
> patch-2.6.24-rc2-lttng-0.10-pre23.tar.bz2:
>   trace_mark(kernel_arch_syscall_entry, "syscall_id %d ip #p%ld",
> 			(int)regs->orig_eax, instruction_pointer(regs));
>   trace_mark(kernel_arch_syscall_exit, MARK_NOARGS);
> For systemtap use, we'd like to have more information than that.  On
> syscall entry, we'd like be able to get the arguments,  On syscall exit,
> we'd like the to be able to get the return value.  In fact, the easiest
> thing would be to supply the same information that audit_syscall_entry()
> and audit_syscall_exit() need.
> Since I'll bet you've already considered this, I'd like to know why you
> decided to go a different way.

Well, the approach taken was to instrument each important system call in
the syscall specific function to be able to actually know what type of
information to record. For instance, if ebx points to a string, the
pointer is not very useful, but the string is.

You have a good point for the syscall exit instrumentation : adding the
return value is trivial and would be very useful.

Could we do better ?

> Thanks.
> -- 
> David Smith
> Red Hat
> 256.217.0141 (direct)
> 256.837.0057 (fax)

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]