Linux DTrace development list
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
	dtrace@lists.linux.dev,
	DTrace development list <dtrace-devel@oss.oracle.com>
Subject: Re: sdt provider and access to the trace_event_raw_* struct
Date: Fri, 4 Oct 2024 15:22:38 -0400	[thread overview]
Message-ID: <ZwBAftV8Ov3FG2jr@oracle.com> (raw)
In-Reply-To: <2d1eebfc-d0ca-4fc8-b6c5-c8fc3a37faa2@oracle.com>

On Fri, Oct 04, 2024 at 04:46:58PM +0100, Alan Maguire wrote:
> On 04/10/2024 15:29, Kris Van Hees wrote:
> > On Fri, Oct 04, 2024 at 12:29:35PM +0100, Alan Maguire wrote:
> >> hi folks
> >>
> >> I've come across a case where I need to trace a kernel tracepoint with a
> >> lot of associated trace info.  It seems that the current approach for
> >> sdt probes looks at the "struct trace_event_raw_<tracepoint_name>"
> >> structure and maps its fields into args[] values, translating each
> >> member into a separate argument.  That works great for tracepoints with
> >> a limited number of fields. However in the case of a tracepoint with a
> >> lot of such fields (i.e. more than the number of args[] supported), it
> >> would be useful to also have a convenient way to access the raw "struct
> >> trace_event_raw_*" data, especially since we have access to it directly
> >> via CTF. It's possible to do this via a hack, e.g. the following works:
> > 
> > You should be able to use the raw tracepoint provider, rawtp,
> > e.g. rawtp:sched::sched_switch
> >
> 
> That's a good help, but I should have clarified that I was hoping for a
> way to get the tracepoint data _after_ it has been massaged into the
> tracepoint form; the above will give me access to the raw arguments that
> are used in tracepoint data setup, but I was hoping to have a way to get
> a pointer to the entire trace structure after it has been assigned. It's
> doable in my case (since the first parameter is always a reference) so
> not a massive deal, but it might be useful enhancement for others.

Can you give an example of where it goes wrong?  I don't see a reason why we
wouldn't be able to support more than the number of arguuments that we store
by default.  I.e. I do think that there is a limitation roght now, but I don't
think there is a hard reason for that.  We ought to be able to support access
to all arguments of the probe without much extra effort.

> Thanks!
> 
> Alan
> 
> >> #!/usr/sbin/dtrace -s
> >>
> >> sdt:sched::sched_switch
> >> {
> >>         s = (struct trace_event_raw_sched_switch *)(arg0-8);
> >>         print(s);
> >> }
> >>
> >>
> >> ...but presumably that only works because the first arg value isn't
> >> scalar. It would be good to have a helper or builtin variable to access
> >> this pointer directly. Maybe there's a better way to do this, or maybe
> >> we could add a helper/builtin to make this pointer accessible? What do
> >> folks think?
> >>
> >> Thanks!
> >>
> >> Alan

  reply	other threads:[~2024-10-04 19:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-04 11:29 sdt provider and access to the trace_event_raw_* struct Alan Maguire
2024-10-04 14:29 ` Kris Van Hees
2024-10-04 15:46   ` Alan Maguire
2024-10-04 19:22     ` Kris Van Hees [this message]
2024-10-07 13:17       ` Alan Maguire

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=ZwBAftV8Ov3FG2jr@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=alan.maguire@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    /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