llvm dev - Jul 2013 - [LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

On Jul 30, 2013, at 12:41 PM, Stephen Lin wrote:
>> Right. What's the point of all the effort devoted to MSVC++ ABI
>> compatibility when Clang doesn't need it for being a top-notch C++
>> compiler on Windows?
> 
> I brought up a similar point a little bit earlier, too....
> 
> It seems like the only necessary condition for being a first-class
> native-code development tool on Windows is to support the platform C
> ABI and the subset of the C++ ABI required by COM, and that is the
> most that any non-MS compiler on Windows tries to do,
Huh? Intel CC supports the MSVC++ ABI. Zortech (Digital Mars) supports it, too
(though the guy who wrote it isn't too proud of that fact--or the fact that
he even wrote that compiler to begin with). Heck, even CodeWarrior supported it
(as Howard Hinnant might well remember), before Metrowerks sold off their x86
compiler backend. In fact, other than GCC, only Borland and Watcom don't
support it, and that's only because they originally developed theirs during
the DOS era, before MSVC++ became the de facto standard compiler. (But Watcom
also used to support MFC development on Windows, so they might have supported it
at one point, too.)
> so I am
> genuinely curious why there is so much effort being spent on the more
> esoteric portions of the ABI?
Because the sad truth is, the Microsoft ABI is the de facto standard on
Windows--just as the Itanium ABI is the de facto standard on Linux and Mac OS.
Many a third-party DLL was compiled against it, and so were a few first-party
ones, like the aforementioned MFC. Not everyone (sadly) has the luxury of
recompiling their DLLs to work with an alternative C++ ABI--and I'd imagine
it'd be a support nightmare for those that do to have multiple binaries out
there in the wild (Welcome to DLL Hell!! :). Seriously, I think they've had
enough trouble with multiple versions; I don't think they want to deal with
multiple C++ ABIs, too. (Naturally, open source software does not have the first
problem, because they *can* just recompile their DLLs to work with
GCC/Clang--which they often do. But still, there's a lot of legacy
proprietary code out there on Windows, and the fact that open source code can be
recompiled does little for the DLL Hell problem.)

The fact that more than one C++ ABI isn't quite compatible with MSVC (not
even enough to support COM, in some cases) is the reason Wine (for example)
doesn't allow C++ code. (And yes, some of their DLLs really do need to
conform to the Microsoft C++ ABI, beyond just COM.) In fact, that was the whole
reason that *I* started this little subproject (supporting the MSVC ABI) in the
first place. (Though I imagine that at least some of this might have taken place
even without me. ;)

You're right that we don't need it to be a great C++ compiler. But we do
need it to attract people who'd otherwise use MSVC (if for no other reason
than ABI compatibility) to our top-notch compiler.

Chip

Charles Davis <cdavis5x at gmail.com> writes:
> Huh? Intel CC supports the MSVC++ ABI. Zortech (Digital Mars) supports
> it, too (though the guy who wrote it isn't too proud of that fact--or
> the fact that he even wrote that compiler to begin with). Heck, even
> CodeWarrior supported it (as Howard Hinnant might well remember),
> before Metrowerks sold off their x86 compiler backend. In fact, other
> than GCC, only Borland and Watcom don't support it, and that's only
> because they originally developed theirs during the DOS era, before
> MSVC++ became the de facto standard compiler. (But Watcom also used to
> support MFC development on Windows, so they might have supported it at
> one point, too.)
MFC is just a library and hence unrelated to the C++ ABI. Borland
produced MFC applications without problem. You need to support some
language extensions, but that's all. Oh, and IIRC you need a license for
using MFC with other compiler than MS. If I'm not mistaken, same
requirement applies to key components such as the C++ runtime/stdlib.
>> so I am
>> genuinely curious why there is so much effort being spent on the more
>> esoteric portions of the ABI?
> Because the sad truth is, the Microsoft ABI is the de facto standard
> on Windows--just as the Itanium ABI is the de facto standard on Linux
> and Mac OS. Many a third-party DLL was compiled against it, and so
> were a few first-party ones, like the aforementioned MFC. Not everyone
> (sadly) has the luxury of recompiling their DLLs to work with an
> alternative C++ ABI--and I'd imagine it'd be a support nightmare
for
> those that do to have multiple binaries out there in the wild (Welcome
> to DLL Hell!! :). Seriously, I think they've had enough trouble with
> multiple versions; I don't think they want to deal with multiple C++
> ABIs, too.
Quite the contrary, knowing that Clang's C++ ABI is completely
incompatible with MS is a maintenance *simplification*.

Saying that supporting the MS C++ ABI is an uphill battle is an
understatement (and better say MS C++ ABI*S*, because it evolved over
time and it is known that it will change on future releases.) As far as
I'm concerned, I'll never base my decisions on compiler usage on the
advertisement of MS compatibility by Clang++, becase I *know* that for a
very long time (maybe forever) whatever MS C++ libraries that work with
Clang++ is by luck. That's what happens when you try to implement
compatibility with an undocumented, propietary, complex feature.
> (Naturally, open source software does not have the first problem,
> because they *can* just recompile their DLLs to work with
> GCC/Clang--which they often do. But still, th ere's a lot of legacy
> proprietary code out there on Windows, and the fact that open source
> code can be recompiled does little for the DLL Hell problem.)
>
> The fact that more than one C++ ABI isn't quite compatible with MSVC
> (not even enough to support COM, in some cases) is the reason Wine
> (for example) doesn't allow C++ code. (And yes, some of their DLLs
> really do need to conform to the Microsoft C++ ABI, beyond just COM.)
> In fact, that was the whole reason that *I* started this little
> subproject (supporting the MSVC ABI) in the first place. (Though I
> imagine that at least some of this might have taken place even without
> me. ;)
>
> You're right that we don't need it to be a great C++ compiler. But
we
> do need it to attract people who'd otherwise use MSVC (if for no other
> reason than ABI compatibility) to our top-notch compiler.
Of course you are free to work on whatever you wish. I'm not criticizing
your work or anybody else's. However, I'm quite surprised to see how a
great deal of energy is invested on MS C++ ABI compatibility without an
end in sight and with some ticklish areas ahead (MS C++ runtime(s)
support, SEH support, complex LLVM change requirements (this very same
thread)) while Clang++ currently cannot do several basic things on
Windows (which of course are also required for being MS compatible.)
Example: dllexport of C++ classes and templates.

I'm also worried by the damage of claims such as "MS C++ ABI is the
standard on Windows", which conveys the message that until Clang++
supports such ABI it can not be a serious contender on Windows. Which is
blatantly false. Fact is that you need MS C++ ABI compatibility only for
using C++ libraries which lack source code. I doubt that the individuals
and organizations that abide such pitiful state are interested on using
a compiler other than the "industry standard" MSVC++, or that the
success of Clang on Windows depend on them at all.

> Quite the contrary, knowing that Clang's C++ ABI is completely
> incompatible with MS is a maintenance *simplification*.
Yes, for example, as explained by Bjarne once, incompatible name
mangling schemes for ABIs that are not guaranteed to be 100% binary
compatible is a _feature_, not a bug, since it prevents anyone from
even beginning to develop a workflow that relies upon linking possibly
incompatible binaries.
>
> Saying that supporting the MS C++ ABI is an uphill battle is an
> understatement (and better say MS C++ ABI*S*, because it evolved over
> time and it is known that it will change on future releases.) As far as
> I'm concerned, I'll never base my decisions on compiler usage on
the
> advertisement of MS compatibility by Clang++, becase I *know* that for a
> very long time (maybe forever) whatever MS C++ libraries that work with
> Clang++ is by luck. That's what happens when you try to implement
> compatibility with an undocumented, propietary, complex feature.
This is my point as well; it just seems odd to spend so much effort to
implement and undocumented ABI with no guarantee of support or
stability (outside of MSVC major version releases). Furthermore, I
feel that, by reinforcing the notion that use of the MSVC++ ABI is
required for development on Windows (when no system-provided libraries
or ABIs require it), Clang developers are hindering the adoption of
Clang on Windows rather than promoting it, since it is unlikely that
any party that is not personally invested in Clang development would
be willing to depend on a backward engineered implementation of a
"required" but undocumented ABI for production use. Furthermore, it
means that Clang will always be behind the curve on Windows, since,
even if MSVC++ ABI support is fully usable one day, no one will be
willing to link it with object files from a new major version of MSVC
without some critical mass of users being guinea pigs first and
ensuring that there are no major bugaboos.

I agree that there is value in supporting implementing full MSVC++
ABI, if it can be done, but it seems like that support can never be
100% complete (or, more to the point, known to be 100% complete)
unless Microsoft itself decides to officially support the
implementation or completely stabilize and document their C++ ABIs.
However, I personally think that it is not only easier, there is more
value in implementing a C++ ABI which is compatible with officially
supported C and COM MSVC++ ABI subsets and consciously _not_
compatible in others way (in particular, which does not even attempt
to link C++ symbols with MSVC++, since that is not required for COM).
This is something that can be made to work and guaranteed (barring
some seriously misguided behavior from Microsoft) to continue to work
stably.

Furthermore, by providing and controlling its own Windows C++ ABI:
Clang can possibly offer something that MSVC *cannot* (and does not
even try to do): a development platform and ecosystem which provides a
stable-over-time C++ ABI and consistent cross-module usage of RTTI,
STL, C++ memory management, etc. (which is dicey even within MSVC
major versions unless the exact same build settings are used, last
time I checked.) This would give someone an active reason to switch to
Clang more than anything else Clang currently offers on Windows.

Stephen