betterC on Win32: execute shared static ctors+dtors#6956
betterC on Win32: execute shared static ctors+dtors#6956WalterBright wants to merge 1 commit intodlang:masterfrom
Conversation
|
Thanks for your pull request, @WalterBright! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. |
fbd7c4d to
2b0fc7c
Compare
| @@ -0,0 +1,21 @@ | |||
| /* REQUIRED_ARGS: -betterC | |||
| * PERMUTE_ARGS: | |||
| */ | |||
There was a problem hiding this comment.
Can TEST_OUTPUT be used here? Currently nothing tests that the ctors/dtors are actually executed.
There was a problem hiding this comment.
Testing the output will come when the other platforms are supported.
|
For linux it's usually just placing a function pointer into a specific section. 👍 to the idea and more betterC work. One thing I was wondering though is that the betterC constructors then have slightly different runtime semantics (construction order is not guaranteed and cyclic module contructor dependencies therefore will be supported in betterC mode). I'm not sure if it is a good idea to change semantics with a compiler switch. An alternative is to use an Ping @andralex as this is some kind of language change / discussion. |
|
Don't pull this yet, I have a better idea. |
2b0fc7c to
536328b
Compare
|
Ok, better idea done. |
andralex
left a comment
There was a problem hiding this comment.
Cool beans. This should come with a changelog entry and documentation. Please fix the bug and perhaps add more test (only ctor/dtor).
src/ddmd/glue.d
Outdated
| { | ||
| if (m.ssharedctor) | ||
| objmod.setModuleCtorDtor(m.ssharedctor, true); | ||
| if (m.ssharedctor) |
There was a problem hiding this comment.
BUG should be if (m.sshareddtor)
There was a problem hiding this comment.
danged copy/pasta errors!
d8de3b7 to
78cbde8
Compare
|
@andralex done |
78cbde8 to
7329086
Compare
|
While this is waiting, there's #6957 for the non-controversial bits. |
7329086 to
d3271c0
Compare
|
Perhaps |
|
Is this the same as We also already have this for ELF targets (Linux and FreeBSD). It was added for the implementation of dynamic libraries. |
schveiguy
left a comment
There was a problem hiding this comment.
I'm against such a change, since D users expect to have proper ordering of D static ctor/dtors regardless of link order. I would recommend instead to simply use the C compiler's feature with that compiler. I can't imagine chasing a bug due to linker order is going to be fun when you switch to -betterC mode.
Just giving my opinion for what it's worth, not expecting a response or acceptance.
|
|
||
| Although D guarantees that static construction for imports occurs first, | ||
| no such ordering guarantee is available with -betterC. Typically, however, the order | ||
| matches the order in which object files are presente to the linker. |
Not having switches that subtly change language semantics is probably a good idea. How about allowing the use of this feature through |
I don't like that either, because I guarantee there is some poor soul who put FYI: there is a discussion about this very thing here: https://issues.dlang.org/show_bug.cgi?id=17747 |
|
It can be implemented using a UDA or pragma, like for GDC and LDC. |
See #7182 |
|
We might close this in favor of #7182 For the unlikely need of a codebase to support both, |
|
Let's go with #7182. Further improvements will come on top of it. |
|
please check on https://issues.dlang.org/show_bug.cgi?id=18100 crt_constructor need to allow set immutable(which mean it only should be call once, and can not been call from main function). If we simple use extern(C) shared static this will fix all problem. |
This uses the mechanism Digital Mars C++ uses to call C++ static constructors and destructors to call D shared static constructors and destructors in
-betterCmode.Each C compiler does it differently, so some research is necessary to figure it out for other platforms.