Re: sdt.h vs comdat

[Mark Wielaard <mjw at redhat dot 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