public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "jistone at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug translator/13155] conflicting tracepoint headers block stap -l / stap -p4
Date: Wed, 05 Oct 2011 19:49:00 -0000	[thread overview]
Message-ID: <bug-13155-6586-t7jaOdGFuG@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-13155-6586@http.sourceware.org/bugzilla/>

http://sourceware.org/bugzilla/show_bug.cgi?id=13155

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com

--- Comment #8 from Josh Stone <jistone at redhat dot com> 2011-10-05 19:47:40 UTC ---
If we accept that the kernel will continue creating issues like this, then
we'll need to start segregating the tracepoint registration and callbacks into
separate compile units.  Those that come from the same tracepoint header could
still share, as an optimization, but they don't necessarily need to.

Our current generated code looks like this for trace("sys_enter"):

> #include <trace/events/syscalls.h>
> #ifdef DECLARE_TRACE_NOARGS
> #define STAP_TP_DATA   , NULL
> #define STAP_TP_PROTO  void *cb_data __attribute__ ((unused)),
> #else
> #define STAP_TP_DATA
> #define STAP_TP_PROTO
> #endif
> static void enter_tracepoint_probe_1(
>     STAP_TP_PROTO
>     struct pt_regs* __tracepoint_arg_regs,
>     long int __tracepoint_arg_id
>     )
> {
[... common entry boilerplate]
>   c->marker_name = "sys_enter";
>   c->probe_locals.probe_2904.__tracepoint_arg_regs = (int64_t)(intptr_t)__tracepoint_arg_regs;
>   c->probe_locals.probe_2904.__tracepoint_arg_id = (int64_t)__tracepoint_arg_id;
>   (*probe->ph) (c);
[... common exit boilerplate]
> }
> static int register_tracepoint_probe_1(void) {
>   return register_trace_sys_enter(enter_tracepoint_probe_1 STAP_TP_DATA);
> }
> static void unregister_tracepoint_probe_1(void) {
>   (void) unregister_trace_sys_enter(enter_tracepoint_probe_1 STAP_TP_DATA);
> }

The registration can easily be moved to a separate file, but enter_tracepoint
is a bit more complicated for mixing the tracepoint's typed arguments and
systemtap's context setup.  We can probably just split it so the arguments are
cast to int64_t ahead of time, something like:

In stap_HASH.c:
> static void stp_enter_tracepoint_probe_1(
>     int64_t __tracepoint_arg_regs,
>     int64_t __tracepoint_arg_id
>     )
> {
[... common entry boilerplate]
>   c->marker_name = "sys_enter";
>   c->probe_locals.probe_2904.__tracepoint_arg_regs = __tracepoint_arg_regs;
>   c->probe_locals.probe_2904.__tracepoint_arg_id = __tracepoint_arg_id;
>   (*probe->ph) (c);
[... common exit boilerplate]
> }

In stap_HASH_tracepoint_probe_1.c:
> static void enter_tracepoint_probe_1(
>     STAP_TP_PROTO
>     struct pt_regs* __tracepoint_arg_regs,
>     long int __tracepoint_arg_id
>     )
> {
>   stp_enter_tracepoint_probe_1((int64_t)(intptr_t)__tracepoint_arg_regs,
>                                (int64_t)__tracepoint_arg_id);
> }

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

  parent reply	other threads:[~2011-10-05 19:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-06 10:43 [Bug translator/13155] New: tracepoints probe breakage phan at redhat dot com
2011-09-07  7:28 ` [Bug translator/13155] " phan at redhat dot com
2011-09-07 10:49 ` mjw at redhat dot com
2011-09-08  5:43 ` phan at redhat dot com
2011-09-12 10:43 ` mjw at redhat dot com
2011-09-12 10:54 ` mjw at redhat dot com
2011-09-13  4:23 ` phan at redhat dot com
2011-09-30 20:46 ` [Bug translator/13155] conflicting tracepoint headers block stap -l / stap -p4 fche at redhat dot com
2011-10-05 19:49 ` jistone at redhat dot com [this message]
2011-10-05 20:47 ` fche at redhat dot com

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=bug-13155-6586-t7jaOdGFuG@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=systemtap@sourceware.org \
    /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).