Non-cloned [cd]tors
Jason Merrill
jason at redhat.com
Wed Nov 18 20:22:50 UTC 2009
As I recall, the ABI was intended to allow the various [cd]tor variants
to be implemented either as separate functions or multiple entry points
to the same function. But the actual specification is a bit problematic
for the latter: it's a bit vague, but it seems to require that any vague
linkage [cd]tors be emitted as needed, each in their own COMDAT group.
But if the two constructor variants are alternate entry points to the
same function, they can't go in different groups. One could be
implemented as a jump to a different symbol in the other group, but that
breaks if the linker chooses a definition of the other group which
doesn't define this symbol.
Does anyone remember how this was supposed to work? It seems like the
only way to deal with it is to add a new COMDAT group, put all the
variants in there, and accept that if you're linking objects from
multiple compilers you may end up with dead code in the output.
We're currently looking at changing G++ to only emit one version of
[cd]tors when they'll be identical (i.e. when the class has no virtual
bases), and in the non-COMDAT case making one symbol an alias to the
other. This special case is not as problematic for the COMDAT case
either, as one function can just jump to the ABI-defined symbol for the
other.
The only situation in which this could be a problem would be if one
compiler decided to make C1 jump to C2 and another compiler made C2 jump
to C1, and we choose one of each and end up with an infinite loop. So
I'd like to specify which one will be the real function if a compiler
decides to do this. I don't have a strong preference; the base variant
is conceptually a subroutine of the complete variant, but the complete
variant is going to be more commonly used.
Adding an extra branch in the COMDAT case does have a performance
impact, so I'd like to do the redirection on the caller side. Since the
two functions must be identical, I don't think there should be any
problem calling a different variant than specified by the ABI; does
anyone disagree?
Jason
More information about the cxx-abi-dev
mailing list