FWIW, we did consider a different scheme. Namely interface units emit the the
standard constructor function that is called via .init_array. But, give the
ctor a priority related to the depth of the interface unit's import graph. Thus
the initializers of any imported interface are run before the initializer of the
importer. (there's a bit of finessing with partitions, but fairly obvious).

IIRC we rejected that as it relied on knowlege of the import graph -- but the
scheme we have does that too. It has the advantage of not needing idempotent
initializers -- they're executed exactly once by design. It does rely on
constructor priorities, but I'm going to presume that any system implementing
the itanium ABI supports them.

Perhaps we should change?

nathan


On 20/10/2024 17:26, Gabriel Dos Reis via SG15 wrote:
> [Jason]
>
> * But if the interface unit doesn't have any dynamic initialization, which I
> would expect to be by far the majority of MIUs, forcing all importers to
> call an empty function seems like an undesirable pessimization to startup.
>
> Exactly.
>
> The MSVC implementation doesn’t have this unnecessary compulsory complication.
>
> -- Gaby
>
> *From:*SG15 <sg15-bounces_at_[hidden]> *On Behalf Of *Jason Merrill via SG15
> *Sent:* Friday, October 18, 2024 2:40 PM
> *To:* sg15_at_[hidden]
> *Cc:* Jason Merrill <jason_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>
> *Subject:* Re: [isocpp-sg15] P3470R0: Interface-Unit-Only Module Library Support
>
> On Thu, Oct 17, 2024 at 2:27 PM Daniel Ruoso via SG15 <sg15_at_[hidden]
> <mailto:sg15_at_[hidden]>> wrote:
>
> Em qua., 16 de out. de 2024 às 19:28, Nathan Sidwell via SG15
> <sg15_at_[hidden] <mailto:sg15_at_[hidden]>> escreveu:
>
> > It is important to note that, in the Itanium ABI, even if the module
> doesn’t currently have
> > anything that needs static initialization, the translation unit
> importing that module will still
> > generate the code to call the initializer, because we don’t want the
> addition of a static initializer
> > to a shared object to result in an ABI break
> this is false.
>
>
> Interesting. That is the current implementation in clang, IIUC.
>
> We probably need to clarify that point, because it is indeed problematic if
> adding a new static initializer means an ABI breakage for the library.
>
> This would be the proposed
>
> https://github.com/itanium-cxx-abi/cxx-abi/pull/144/files#diff-
> b803017e5afd1b6dfe35e5e0e719d895559129c35b93f056074a72928269ae23R5034 <https://
> github.com/itanium-cxx-abi/cxx-abi/pull/144/files#diff-
> b803017e5afd1b6dfe35e5e0e719d895559129c35b93f056074a72928269ae23R5034>
>
> It's not clear to me why calling this initializer would be necessary for a
> shared object anyway, since loading the shared object will run its
> initialization before that of the executable.
>
> I think this was intended to make the <iostream> __ioinit trick work in a
> modules world; with that trick, any TU that included the file got a static
> initializer that runs before anything else. So similarly, if you import an
> interface unit with a static initializer, you need to run it first. But if the
> interface unit doesn't have any dynamic initialization, which I would expect to
> be by far the majority of MIUs, forcing all importers to call an empty function
> seems like an undesirable pessimization to startup.
>
> The ABI break is not on adding a static initializer to a shared object; it's on
> adding a static initializer to a module interface unit that isn't in a shared
> object, and even then you only lose the order of initialization guarantee
> (unless you use attribute init_priority). This seems acceptable to me.
>
> Jason
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15

-- 
Nathan Sidwell