tool-conventions
tool-conventions copied to clipboard
WebAssembly
Specify version and abi information in "linking" section header
Hmm, I'd rather not increase the complexity that much. We had discussed a single version string, since main use case is simply to prevent linking incompatible modules. The scheme I'm proposing here is a little more explicit. An array if key-value pairs seems most complex.. but I could be persuaded.
In terms of the C++ features like EH, I imagine that would be a bit in the ABIFlags, no? Wouldn't that work?
In terms of the cost of C users of combining the C and C++ abis into one, I don't think that having to rebuild your objects when the C++ abi revs is very big cost.
The cost isn't just rebuilding your own objects. It's also getting objects that you didn't build yourself rebuilt. Which isn't a big deal for some users, but is for others. And in a mixed-language world, it includes getting all your compilers to agree on which version to use.
I also like keeping C and C++ separate because while C is well-established as a base language for communicating between different high-level languages, and between libraries that want to maintain stable interfaces (eg. LLVM's C API), C++ isn't, so I don't see a reason to give C++ a special status here.
Key-value pairs would let us put a C++ ABI field in there (or two, one for language and one for standard library, if we wanted that), and also leave room for other languages to define their own ABI fields. But they are also more complex to decode and implement.
I've been thinking about it and I think I agree with you after all :) I will update the PR.
BTW I kind of like the version info being in the header of the section rather than in one a subsection. What do you think about doing this?
I'm still having trouble seeing how this extra information would be used. The simplest thing is to say that all fields have to match exactly, but that is no better than just having a single version number (right?)
So I assume we're talking about allowing objects with slightly different flag fields to link together, but I'm not sure I understand what the rules would be. Is it just ad-hoc?
What's the target for this ABI info - is it for describing static linking, or dynamic, or both? Dynamic linking is in a sense a smaller thing, although it's bigger because it's not yet nailed down at all.
Whereas if we're targetting static linking, then the ABI can just be a single string.
Making the C++ ABI stable across different dynamically-linked objects is probably a stretch goal at this point, although I guess the ABI-string should be able to specify it.
We aren't expecting to bump the ABI often, I wouldn't have thought...
My understanding is that static and dynamic linking will have the same requirements. i.e.: they both need to answer the question: "Can the code in one object inter-operate with the code in another".
If two DLLs written in C++ need to inter-operate then the will need to agreee on the C++ ABI. I suppose they could inter-operate via the C ABI despite being written in C++?
And yes, the idea is the change these ABIs as infrequently as possible.
I'm still not sure exactly how much detail we want to include there. For most existing platforms, its kind of left up to the programmer to ensure the abi matches. For example I don't think ELF includes this level of detail. Hence I decided to split of the versioning of the metadata which is less controversial.