public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: David Smith <dsmith@redhat.com>
Cc: ltt-dev@shafik.org, Systemtap List <systemtap@sources.redhat.com>
Subject: Re: patches to actually use markers?
Date: Fri, 16 Nov 2007 19:24:00 -0000	[thread overview]
Message-ID: <20071116192415.GA25794@Krystal> (raw)
In-Reply-To: <473DEBB7.40607@redhat.com>

* David Smith (dsmith@redhat.com) wrote:
> David Smith wrote:
> > Mathieu Desnoyers wrote:
> >> * David Smith (dsmith@redhat.com) 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
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 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

  reply	other threads:[~2007-11-16 19:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 19:26 David Smith
2007-10-29 22:05 ` Mathieu Desnoyers
2007-10-31 16:29   ` David Smith
2007-10-31 16:58     ` Mathieu Desnoyers
2007-10-31 18:12       ` Mathieu Desnoyers
2007-11-01  3:34         ` Mathieu Desnoyers
2007-11-16 19:13     ` David Smith
2007-11-16 19:24       ` Mathieu Desnoyers [this message]
2007-11-16 19:56         ` Frank Ch. Eigler
2007-11-16 20:10           ` Mathieu Desnoyers
2007-11-16 20:27             ` Frank Ch. Eigler
2007-11-16 20:35               ` Mathieu Desnoyers
2007-11-16 20:43                 ` Frank Ch. Eigler
2007-11-16 22:03                   ` Mathieu Desnoyers
2007-11-16 22:35                     ` Frank Ch. Eigler
2007-11-20 16:50                       ` Mathieu Desnoyers
2007-11-20 15:22         ` David Smith
2007-11-20 16:22           ` [Ltt-dev] " Mathieu Desnoyers
2007-11-20 20:43             ` David Smith
2007-11-20 18:46           ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071116192415.GA25794@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=dsmith@redhat.com \
    --cc=ltt-dev@shafik.org \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).