Re: WG21 ABI study group

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2024-05-12 23:51:08

On 10/05/2024 23:01, Ville Voutilainen wrote:

> Are you going to make std::string a COM type with interface
> indirections? tuple? pair?

You are correct that ABI resiliency historically came with a runtime 
overhead penalty.

If a linker can devirtualise final classes, it certainly can de-indirect 
interface indirections.

The prototype I built at BlackBerry didn't implement the runtime 
de-COMification stage, but it did emit all necessary metadata so a 
linker stage could do so in linear time. The way I had it was if 
compatible toolchains were used both sides of the ABI boundary, you got 
linking like now. If they differed, you got varying amounts of runtime 
overhead generated, with the worst being two toolchains with different 
calling conventions.

As to whether to make all types which touch a nu-COM boundary be 
required to be also nu-COMed themselves ... I guess it depends on the 
impact on link times.

If Modules can be implemented in a way where link times are bounded, 
then nu-COMifying everything is surely doable with bounded times. It is 
hard to do better than speculation here, but for sure for Debug builds 
we can have fast links and only for optimised builds do we invest more 
time on linking. I think it would work.

>> tried to effectively propose a modernised COM for C++ Modules
>> originally, and to say that went down like a lead balloon would be
>> putting it mildly.
> 
> I have absolutely no idea what you're talking about there. I cannot
> find a Modules proposal that does
> anything of the sort. Please point to the proposal you think you're
> talking about.

I don't think it ever made it as far as a formal WG21 paper. Gaby 
described it to me over dinner one evening, otherwise I wouldn't know 
about it either.

The essence of it was https://github.com/GabrielDosReis/ipr, and your 
compiled C++ Module would be a shared library binary with an IPR 
interface description embedded into it. Your C++ process runtime loader 
would no longer use the ELF or PE symbol tables to link up the shared 
library binaries into a process, it would parse the IPR for the 
precompiled C++ Modules in the link database, assemble them into a 
graph, generate any thunk code as needed between them, and thus birth 
the process. This is why LLFIO works before main() gets called 
incidentally, I originally intended it to be used to bootstrap C++ 
Modules based C++ programs into existence.

 From what he told me, some within C++ tooling did not like there being 
a  standard binary interface for Modules. As in, over my dead body 
showstopper red line no. So that got dropped very early on as it was 
politically infeasible to standardise, plus historically speaking WG21 
has not told implementations exactly how to implement tooling, so it 
would have been a big land grab and a big ask to dictate to all 
implementations "all C++ Modules shall be implemented in this EXACT 
binary format".

The C++ Modules we eventually got I think you'll agree got very 
considerably watered down even after the first WG21 papers appeared, so 
it was probably right that it was too big an ask of WG21 to standardise 
C++ Modules as a newly modernised COM of toolchain independent binary 
objects. No point proposing something impossible.

Niall