What does COMDAT stand for?

[vl106]

I got the idea what is behind the linkage on function level. So I am just
curious what COMDAT stands for. COMmon DATa is my guess. But
isn't it mostly used for functions?

[Carl Daniel [VC++ MVP]]

Post by vl106
I got the idea what is behind the linkage on function level. So I am just
curious what COMDAT stands for. COMmon DATa is my guess. But
isn't it mostly used for functions?

Yes and Yes.

-cd

[Holger Grund]

Post by vl106
I got the idea what is behind the linkage on function level. So I am just
curious what COMDAT stands for. COMmon DATa is my guess. But
isn't it mostly used for functions?

If you talk about /Gy (aka function-level linking) this is one of the cases
where the compiler emits data in COMDAT sections.

But COMDATs (or COMDAT groups) are required for C++ linkage in
several contexts:

- (referenced) inline functions (multiple definitions in different
translation units do not violate the ODR)
- Virtual Tables (VTT & VFTs) for a class need to be emitted
somewhere.
Some implementation use decider functions, but in some cases the
constructors/destructors and tables need to be emitted for every
translation unit. Consequently multiple definitions must not result
in a linker error.
- all things associated with the two above (virtual functions referenced,
local static variables, local static initialization guards, initializers,
nontrivial literals (although many compilers fail to get that right))
- (VC++ specific) __declspec(selectany) is placed in a COMDAT.

/Gy is for eliminating unused functions, which is only an optimization
and not required to make things work at all. /Gy also generates
COMDATs which do not allow duplicate definitions.

So COMDATs are not necessarily used for funcitons only,
but there is no corresponding optimization for /Gy for data (and
I have actually asked for that once but MS have no plans to do
that).

And yes, if I were to design linkage model C++ today, I would
do things quite differently ...

-hg

[Bruno van Dooren]

Post by Holger Grund
And yes, if I were to design linkage model C++ today, I would
do things quite differently ...

For starters, you'd probably want to specify an ABI as well as an API to
finally ensure compatibility between compiler versions for identical class
declarations.

Actually, is there a reason why there is no ABI? or is it simply because
there were different implementations before there was a c++ language commitee?

[Holger Grund]

Post by Bruno van Dooren

Post by Holger Grund
And yes, if I were to design linkage model C++ today, I would
do things quite differently ...

For starters, you'd probably want to specify an ABI as well as an API to
finally ensure compatibility between compiler versions for identical class
declarations.

AFAICT, there is. The VC++ IA-32 ABI (I don't think it has always
been called like that and quite honestly, the term doesn't really make
much sense) has been mostly stable. At least, I've heard something
along the lines of "unfortunately we can't fix this because it'd break
binary compatibility" from some the VC compiler folks more than once.

It's simply not documented. Not sure what you mean with API here?
An API specification in the common sense is not required for
identical class declarations to have identical layout, symbol
binding & visibility, removal semantics, dependencies etc.

Post by Bruno van Dooren
Actually, is there a reason why there is no ABI? or is it simply because
there were different implementations before there was a c++ language commitee?

I'm confused now. Do you talk about the a generic ABI (for x86) - generic
in that it is supported by several compiler vendors? There's the generic C++
ABI (which is effectively the Itanium ABI). The C++ language standard
aims at allowing maximum flexibility for implementers.

Anyway, specifying an API for the library is nontrivial. The ARM EABI
tries to do so for C90 and C99. Several things in there come at a price.

But specifying a common object-level specification for the various
existing standard C++ library implementation is a rather monumental
task.

-hg

[Bruno van Dooren]

Post by Holger Grund
I'm confused now. Do you talk about the a generic ABI (for x86) - generic
in that it is supported by several compiler vendors? There's the generic C++
ABI (which is effectively the Itanium ABI). The C++ language standard
aims at allowing maximum flexibility for implementers.

Sorry for the confusion.
What I meant with ABI was a definition of what a given class looks like in
memory.
I know that different compilers have different ideas about this.
The only thing for which almost anyone shared a common definition were
vtables, which is the reason that COM can be used by all compilers these days.

If only all compilers had the same memory layout for a given class,
reusability of code would be far easier than now.

[Carl Daniel [VC++ MVP]]

Post by Bruno van Dooren

Post by Holger Grund
And yes, if I were to design linkage model C++ today, I would
do things quite differently ...

For starters, you'd probably want to specify an ABI as well as an API to
finally ensure compatibility between compiler versions for identical class
declarations.
Actually, is there a reason why there is no ABI? or is it simply because
there were different implementations before there was a c++ language commitee?

Newer platforms, such as Itanium, do have an official C++ ABI. There was
simply too much divergent practice in place at the time of the C++ standard
to even attempt an ABI for most platforms - including x86/Windows.

In the past, many compilers, like gcc, changed their ABI with every new
release (although I believe gcc has settled down in recent versions, it used
to be quite a mess). As Holger replied, the de-facto VC++ ABI has actually
been quite stable since VC++ 1.0, 32bit Edition which came out well over 10
years ago - too bad the other Windows C++ compiler vendors (other than
Intel) chose to go their own way. No doubt the undocumented nature of the
ABI contributed greatly to that trend!

-cd

[Holger Grund]

Post by Carl Daniel [VC++ MVP]

Post by Bruno van Dooren
Actually, is there a reason why there is no ABI? or is it simply because
there were different implementations before there was a c++ language commitee?

Newer platforms, such as Itanium, do have an official C++ ABI. There was
simply too much divergent practice in place at the time of the C++
standard to even attempt an ABI for most platforms - including
x86/Windows.

Hu? I guess that depends on what you understand under "C++ ABI"
and "official".

There are so many things in the Itanium C++ ABI that only make sense
under *nix. I must admit I have never really taken a closer look at VC++
codegen for IA-64, but I doubt it has much in common with the
IA-64 ABI (calling convention is about the only thing I can think of
right now).

So unless I'm seriously mistaken, MS doesn't implement what I
know as Itanium C++ ABI at all (at least not as GCC does for
almost all platforms now).

Post by Carl Daniel [VC++ MVP]
years ago - too bad the other Windows C++ compiler vendors (other than
Intel) chose to go their own way. No doubt the undocumented nature of the
ABI contributed greatly to that trend!

Yes, and believe me some of the less obvious details of the ABI are
quite hard to find out (e.g. when VC at some point changed the
behavior to adjust the VTT after calling a __declspec(dllimport)ed
constructor)

-hg

[Carl Daniel [VC++ MVP]]

Post by Holger Grund

Post by Carl Daniel [VC++ MVP]

Post by Bruno van Dooren
Actually, is there a reason why there is no ABI? or is it simply because
there were different implementations before there was a c++ language commitee?

Newer platforms, such as Itanium, do have an official C++ ABI. There was
simply too much divergent practice in place at the time of the C++
standard to even attempt an ABI for most platforms - including
x86/Windows.

Hu? I guess that depends on what you understand under "C++ ABI"
and "official".
There are so many things in the Itanium C++ ABI that only make sense
under *nix. I must admit I have never really taken a closer look at VC++
codegen for IA-64, but I doubt it has much in common with the
IA-64 ABI (calling convention is about the only thing I can think of
right now).

Of course, just because there *is* an official ABI, that doesn't compell
implementers to adhere to it. Sadly.

-cd

[Holger Grund]

Post by Carl Daniel [VC++ MVP]

Post by Holger Grund
There are so many things in the Itanium C++ ABI that only make sense
under *nix. I must admit I have never really taken a closer look at VC++
codegen for IA-64, but I doubt it has much in common with the
IA-64 ABI (calling convention is about the only thing I can think of
right now).

Of course, just because there *is* an official ABI, that doesn't compell
implementers to adhere to it. Sadly.

Truth. But then it was definitely much simpler to migrate GCC to IA64 ABI
then it would have been for other toolchains including VC. And quite
honestly, I don't think anyone would really want to move from MS-COFF
to ELF for C++ because its significantly more useful COMDAT support,
much more powerfull directive section support and symbol aliasing
functionality (Dealing with COMDATs - which BTW translates to
group sections in ELF regardless of the COMDAT flag - is a pain)

-hg