On Fri, 2008-03-28 at 02:33 +0100, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 27/03/2008 hora 15:23:
> > 2. Include the ASTs (or equivalent) in the static archive
> > library that accompanies the dynamic library. Generate
> > any missing code at static link time or (if the linker
> > supports link-once semantics) at module compile time.
> >
> > Issue: This has an unintended consequence: any instance that
> > is pre-instantiated by the library now becomes part of
> > the link layer interface contract, because the runtime
> > system cannot instantiate it at run time.
>
> Isn't it possible for the static linker to always instantiate all
> instances that it needs, even if they have already been somehow? That's
> what you obtain with C++ templates, AFAICT (except that they're not
> instantianted at link time, but at compile time).
It is possible, but this leads to the version drift issue that I
outlined. You compile against dynamic library version 1.10. The linker
expands the 1.10 versions of procedures into the executable (not into
the library). The library gets updated to 1.11, and a bug is fixed in
one of those functions. You don't get the update, because the expanded
versions from 1.10 remain in the static linker.
I suppose it would also be possible to use some form of pre-linking to
do this on the target system on demand, but you can see that the problem
is starting to get complicated. Complexity != good.
Concerning template expansion, I think you will find that support in
linkers is highly variable. In the gnu tool chain, these are emitted
with "link once" semantics, but the implementation of link once is
deficient. If you take two object files a.o and b.o, each containing
identical link-once copies of some template, and run
ld -r -o intermediate.o a.o b.o
you will find that the link-once section appears only once in
intermediate.o, but the link-once attribute has not been propagated into
intermediate.o.
> On the other hand, being able to provide pre-instantiated instances
> could be a useful optimization WRT code size, compared to C++ templates.
Yes. And that is why the pre-instantiation option should be supported.
What I would like to avoid is any outcome where the decision about which
pre-instantiations were placed in the dynamic library becomes part of
the dynamic library's interface contract. The binding mechanism should
use any pre-instantiation that is found in the library, but it should be
prepared to instantiate new versions as needed.
There is also a hidden issues for optimization here: run-time code
generation is notoriously incompatible with decent optimization.
> ... if some instances are known to be used among a vast
> project, you can create a library to make those instances available.
At first glance, this is a dicey idea, because there is a potential for
version drift. On the other hand, I definitely see why it is appealing.
I shall give some thought to how the versioning issues here might be
managed coherently.
I will not try to resolve this before we have a fully working BitC
environment -- it's going to have to wait.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
