This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: sdt.h vs comdat
- From: Mark Wielaard <mjw at redhat dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Wed, 11 Aug 2010 14:32:35 +0200
- Subject: Re: sdt.h vs comdat
- References: <20100811085240.07486402C8@magilla.sf.frob.com>
> There is mention of this in PR10512 and
> testsuite/systemtap.base/cxxclass.cxx
> is supposed to be related to that. But I can't really tell what that
> example is intended to test. No test for a COMDAT case can really be
> testing the crux of the COMDAT issue unless it links multiple files
> together, which that test does not.
> [...]
> So, the current sdt.h doesn't handle it either. I guess all the talk
> in PR10512 was just speculative, since we don't have anything like the
> __attribute__ ((section)) way of defining the data mentioned there.
Yes it was. There were a couple of theories why the old sdt.h constructs
didn't work. To be clear the bug and testcase are about constructs seen
in the java/hotspot c++ code where we have static markers in
constructors and destructors. These didn't work before, when there was
usage of __attribute__ ((section)), and usage of computed gotos (GCC bug
#41090) but now do. The testcase is there to make sure we don't regress.
As comment #11 said: "Although this doesn't fix the general comdat
section issue, it does fix the issue at hand ... When we find other C++
related issues we should open a new bug."
> As PR10512 mentions, C/C++ data declarations using __attribute__
> ((section)) implicitly do the right thing. You say section "foo", and
> the compiler actually emits COMDAT section "foo" in the COMDAT group
> of the containing function.
Modulo a bug that prevents you from doing that when you mix C and C++
code: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091
"Using section attribute in c and c++ function causes section type conflict"
Cheers,
Mark