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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.