Date: Sun, 20 Oct 2024 21:26:32 +0000
[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
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
* 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
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
Received on 2024-10-20 21:26:36