COMDAT

[Jim Dehnert]

> From: Mark Mitchell <mark at codesourcery.com>
> 
> When the ABI specifies that things must be placed in the same COMDAT
> group, does that really matter?
> 
> For example, suppose that you put all virtual function thunks in
> COMDAT groups, using the mangled name of the thunk as the name of the
> COMDAT group.  (This is sub-optimal because you cannot use the
> fall-through implementation of thunks, but that's not an ABI issue.)
> Should this be allowed by the ABI?
> 
> (Right now, the ABI specifies that you must put the virtual function in
> the same COMDAT group as the thunked-to function.)


> From: Jason Merrill <jason at redhat.com>
> 
> ...  If they are not in the proper COMDAT group, but are weak,
> the semantics should be the same other than a waste of space.


> From: Mark Mitchell <mark at codesourcery.com>
> 
> That was what I thought, too, but I was not 100% sure about the
> semantics of COMDAT.  Jim, if the changes this entails are too
> substantial, perhaps a single paragraph somewhere at the top saying
> something like:
> 
>   In all cases where this document states that symbols be placed in
>   COMDAT groups with particular names, an implementation is free to
>   place the symbol in an alternate location, provided that the
>   symbol is weak.  This document describes a space-efficient
>   implementation, combining more than one entity into single COMDAT
>   groups in order to avoid wasting space, but separating those
>   entities into individual COMDAT groups or simply making the symbols
>   weak, but not a member of any COMDAT group, is also a correct
>   implementation of the ABI.
> 
> Does that sound about right?

First, correctness.  The only problems I can think of would be
(1) if a non-weak symbol caused a conflict with the "correct" version
in the COMDAT group; or (2) if a COMDAT group with the specified name
but missing some of the specified contents (e.g. because they had been
put in different groups) prevented kept the "correct" version from
being loaded, but didn't cause all of the required contents to be
loaded.  I think your wording excludes the first problem, and could
mostly be extended to avoid the second, although vendors' different
definitions of how weak symbols behave in DSOs may prevent getting it
right if the main executable has an incomplete set of weaks and a DSO
has the full set in a COMDAT.

However, with respect to what the ABI should say, I'd rather not.
The reason is that the usual "as if" rule makes it unnecessary.  (We
haven't explicitly stated the rule -- I always assume it -- but could.)
And if we put in an explicit statement about a permissible alternative,
that could be interpreted as allowing the alternative even if it turns
out that it's not really equivalent for reasons we didn't anticipate.

We do have the examples document, that includes some implementation
suggestions.  I wouldn't mind putting something there about this, with
sufficient caveats...

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272