On 2012-08-17 14:13:10 +0000, "R Grocott" <[email protected]> said:
On Friday, 17 August 2012 at 13:42:27 UTC, Michel Fortin wrote:
It's certainly doable if you put it at the right place. But druntime is
not the one in charge of dynamic linking: the dynamic linker from the
OS is, so that's the ideal place to do such a thing. If you want to do
it in druntime it'll be a huge hassle, if doable at all it'll probably
break easily. But on the OS side you hit a rock because of different
approach to dynamic linking (Windows does not really have a dynamic
linker).
So basically, any system to create a more sensible ABI needs to built
on top of the C ABI, name mangling, editable vtables, and nothing else?
Ouch.
That's pretty much it yes.
If druntime can't detect whether symbols were dynamically or statically
linked, does that mean that your system would add an overhead to *all*
virtual function calls, not just those which call into a dynamic
library?
Yes. Neither druntime nor the compiler knows whether you're creating an
executable. The typical compilation process is to convert D code to an
object file containing machine code. Then that object file is linked
either inside an executable or inside a shared library. But the machine
code is written before the compiler knows where it'll go.
If so, that'd be a pretty strong argument against implementing anything
like it, unless it's something which has to be explicitly switched on
(using, say, an "extern(D_FlexibleABI)" statement).
Exactly my thoughts.
--
Michel Fortin
[email protected]
http://michelf.ca/
