Bug 17868 – add pragma(crt_con/destructor)

To allow people some low-level integration with CRT construction/destruction. An optional priority between 101 and 65535 is supported by GCC/clang (using sorted .init_array.* sections, e.g. .init_array.101). We should match that C/C++ implementation. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-destructor-function-attribute There is also init_priority for C++ static initializers. It relies on the same priority mechanism. https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#index-init_005fpriority-variable-attribute The priority sorting is only implemented when using the GNU/Linux linker, we need to check whether we can implement it for other platforms.

This looks terrible (the original feature I mean). Do we really want to add this to D? Can't someone just use a C/C++ compiler?

(In reply to Steven Schveighoffer from comment #1) > This looks terrible (the original feature I mean). Do we really want to add > this to D? Can't someone just use a C/C++ compiler? What's terrible about that? It's necessary for low-level integrations, and as it isn't standardized between C compilers it would be very helpful to make it at least uniformly accessible in D. It is definitely needed in any case, and obviously gdc/ldc already support it (each with their own syntax). So this enhancement is mainly about dmd and a portable syntax between D compilers.

Why is it terrible? Because absolute numbers are used for ordering, with no central determination of who should use what number. D is far more sane on this subject. Why is it needed? Can't you just use your local C compiler to add the functions? If it's so different and possibly not supported, why do we want D to get involved here? file.d: extern(C) void myModulector() { // construct } extern(C) void myModuledtor() { // destroy } file.c: constructor (1) // no idea of syntax exactly. void myModulector(); destructor(1) void myModuledtor();

I guess these construction/destruction mechanisms are a special case of putting function pointers into specific sections of the data segment. I'd prefer to not implement the special case, but the more general https://issues.dlang.org/show_bug.cgi?id=16300 This enables "system programming" by not adding every special case to the compiler as it is done so far.

I've changed my mind a bit on this. It's OK to have a pragma that allows stuffing function pointers into a section for compiler purposes, obviously we already have custom pragmas anyway. But I still am leary of adopting the "integer priority" as an official API for it. What may be better is: pragma(ctr_constructor[, custom args]) Where custom args would vary based on what the compiler supports. This way, the ctr_constructor part is standardized, but the custom args obviously depend on support from the specific compiler. Use version statements as needed.

(In reply to Rainer Schuetze from comment #4) > This enables "system programming" by not adding every special case to the > compiler as it is done so far. It's a common enough use case to warrant a separate pragma. Also just adding pointers to a section is not enough, the section needs to be flagged accordingly for this to work (e.g. on OSX and ELF). See WIP https://github.com/MartinNowak/dmd/tree/fix17868. > Where custom args would vary based on what the compiler supports. This way, the ctr_constructor part is standardized, but the custom args obviously depend on support from the specific compiler. Use version statements as needed. Version statements for pragmas are a pain, you need to add a forwarding function or repeat the implementations. version (DMD) pragma(constructor, 1234) void func() { /* repeat */ } else pragma(constructor) void func() { /* repeat */ } Pragma arguments don't expand AliasSeq tuples, so that cannot be used either. Also priority support is platform/linker dependent, not compiler dependent. IMO simply making it only do sth. on supported platforms is an easy solution to this. I'd rather drop support for priorities instead of complicating the usage, leaving priorities to GDC/LDC's non-standard intrinsics. We're not that likely to ever need it, but then again it would be cheap to just implement it right away, and someone coming from C/C++ might want to use it.

Let's drop the priority for now, too much hassle to debug OMF and optlink, wasn't supportable on OSX anyhow.

What's the difference between this and `shared static this()` ?

(In reply to Walter Bright from comment #8) > What's the difference between this and `shared static this()` ? This uses the C runtime's features to do static ctor/dtor (if the compiler supports it), shared static this uses D's ModuleInfo to do it.

Commit pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/276df5b9e95012475077f20a6662a0e386f9d68e fix Issue 17868 - add pragma(crt_con-/destructor) - allows to run con-/destructors before/after CRT startup/shutdown - primary use-case is implementing modular startup in druntime itself

Commit pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/276df5b9e95012475077f20a6662a0e386f9d68e fix Issue 17868 - add pragma(crt_con-/destructor)

*** Issue 17035 has been marked as a duplicate of this issue. ***