Evaluate global constructors (life before main)

[oli-obk]

@eddyb is lawful evil https://github.com/neon-bindings/neon/blame/master/src/lib.rs#L49

basically we should look in platform specific link sections for statics and run their value before anything else

#[cfg_attr(target_os = "linux", link_section = ".ctors")]
#[cfg_attr(target_os = "macos", link_section = "__DATA,__mod_init_func")]
#[cfg_attr(target_os = "windows", link_section = ".CRT$XCU")]
pub static __FOOMP: extern "C" fn() = {
    extern "C" fn __foomp() {
        // life before main goes here
    }
    __foomp
}

This would also help support the inventory crate.

[Ericson2314]

🤮 @eddyb!

[RalfJung]

Are you sure about the "lawful" part? :P

More seriously though -- shouldn't we instead lobby for some way to express this in Rust proper? I already feel bad about that TLS emulation we are doing...

[eddyb]

shouldn't we instead lobby for some way to express this in Rust proper?

No, Rust as a language is uninterested in life-before-main. The only reason any of this works is because it's an OS feature we can't really stop you from opting into.

[RalfJung]

See rust-lang/rust#66862 (comment) for more information on these sections.

[joshtriplett]

You might find the following C program useful for experimenting with init section order:

#include <stdio.h>

typedef void (*FN)(void);

#define MKINIT(function, section) \
    void function(void) { puts(section); } \
    __attribute__((__section__(section))) FN function##_section[] = { function };

MKINIT(init_array, ".init_array")
MKINIT(init_array_00001, ".init_array.00001")
MKINIT(init_array_00002, ".init_array.00002")
MKINIT(init_array_65533, ".init_array.65533")
MKINIT(init_array_65534, ".init_array.65534")
MKINIT(fini_array, ".fini_array")
MKINIT(fini_array_00001, ".fini_array.00001")
MKINIT(fini_array_00002, ".fini_array.00002")
MKINIT(fini_array_65533, ".fini_array.65533")
MKINIT(fini_array_65534, ".fini_array.65534")
MKINIT(ctors, ".ctors")
MKINIT(ctors_00001, ".ctors.00001")
MKINIT(ctors_00002, ".ctors.00002")
MKINIT(ctors_65533, ".ctors.65533")
MKINIT(ctors_65534, ".ctors.65534")
MKINIT(dtors, ".dtors")
MKINIT(dtors_00001, ".dtors.00001")
MKINIT(dtors_00002, ".dtors.00002")
MKINIT(dtors_65533, ".dtors.65533")
MKINIT(dtors_65534, ".dtors.65534")

int main(void)
{
    puts("main");
    return 0;
}

This prints:

.ctors.65534
.init_array.00001
.ctors.65533
.init_array.00002
.ctors.00002
.init_array.65533
.ctors.00001
.init_array.65534
.init_array
.ctors
main
.dtors
.fini_array
.fini_array.65534
.dtors.00001
.fini_array.65533
.dtors.00002
.fini_array.00002
.dtors.65533
.fini_array.00001
.dtors.65534

Note that weird things happen if you try using 00000 or 65535 or numbers outside that range, or non-numeric suffixes; the entire list gets sorted strangely if you do that. I don't think you need to worry about reproducing that exact behavior, though; I think that's a linker script quirk that doesn't normally come up because GCC never emits sections with such "weird" suffixes. Also note that the aforementioned weirdness may differ between GNU ld and LLVM's lld.

[RalfJung]

Thanks! We'll need to turn this into a Rust program as a test for this feature, but that shouldn't be too hard I guess.

Note that weird things happen if you try using 00000 or 65535 or numbers outside that range, or non-numeric suffixes; the entire list gets sorted strangely if you do that. I don't think you need to worry about reproducing that exact behavior, though; I think that's a linker script quirk that doesn't normally come up because GCC never emits sections with such "weird" suffixes. Also note that the aforementioned weirdness may differ between GNU ld and LLVM's lld.

Sounds like it would be best to just make Miri error in those cases.

[oli-obk]

We also need to bail if two entries for the same link section exist

[joshtriplett]

@oli-obk No, you can have arbitrarily many entries in a section; it's an array of function pointers. Entries for the same section get concatenated in link order.

[RalfJung]

How does one detect the length of the array? Do link sections have a notion of "length"?

[oli-obk]

Entries for the same section get concatenated in link order.

I don't think miri can figure out link order. For now we can bail out on multiple entries for the same section, but in the future we can check that they are order independent instead