public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "mjw at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sources.redhat.com
Subject: [Bug runtime/10512] New: STAP_PROBES don't work in c++ constructors/destructors
Date: Wed, 12 Aug 2009 14:58:00 -0000	[thread overview]
Message-ID: <20090812145803.10512.mjw@redhat.com> (raw)

The problem is that the current way the STAP_PROBE macros are defined in sdt.h
doesn't work nicely with COMDAT sections. The linker might throw away the COMDAT
section that contains the code g++ generates for the class
constructors/destructors that our .probes section refers to.

There is no easy way to figure out whether the current code section is in a
COMDAT group or not when using a gas .section pseudo-op.

But if we would define the data section as a C static variable with an
__attribute__ ((section (".probes"))) is seems gcc inherits the COMDATness of
the current code section.

Currently the labels used for identifying the probe points are defined inside
the asm statements. Roland suggested using something like an extern void label
asm (".Llabelname") to reuse them on the C side. The STAP_PROBE_DATA could then
be expressed like:

  static const struct                                                   \
    {                                                                   \
      int guard __attribute__((__aligned__(4)));                        \
      void *probe_addr __attribute__((__aligned__(8)));                 \
      void *name_addr __attribute__((__aligned__(8)));                  \
    } probe __attribute__((__aligned__(8)), (section (".probes")))      \
    = {guard, &label, #name}

-- 
           Summary: STAP_PROBES don't work in c++ constructors/destructors
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mjw at redhat dot com


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

             reply	other threads:[~2009-08-12 14:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-12 14:58 mjw at redhat dot com [this message]
2009-08-12 15:00 ` [Bug runtime/10512] " mjw at redhat dot com
2009-08-12 18:29 ` jistone at redhat dot com
2009-08-14  9:05 ` mjw at redhat dot com
2009-08-14  9:40 ` mjw at redhat dot com
2009-08-14 10:07 ` mjw at redhat dot com
2009-08-17 10:26 ` mjw at redhat dot com
2009-08-17 12:09 ` mjw at redhat dot com
2009-08-17 14:03 ` mjw at redhat dot com
2009-08-17 22:25 ` mjw at redhat dot com
2009-08-18 10:54 ` mjw at redhat dot com
2009-08-18 10:55 ` mjw at redhat dot com
2009-08-18 21:41 ` mjw 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=20090812145803.10512.mjw@redhat.com \
    --to=sourceware-bugzilla@sourceware.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).