Add support for global constructors (i.e. life before main)

[ibraheemdev]

This should resolve #450.

I verified that the inventory crate now works locally on my machine (Linux), but I'm not sure how this should be tested. Would adding inventory as a dependency for tests be acceptable, or should we setup the ctors manually?

[RalfJung]

Thanks for the PR. :)

I would appreciate a test that does the setup itself, that's much easier for debugging future issues should they arise.

[bjorn3]

Suggested change

	link_section = "__DATA,__mod_init_func"
	link_section = "__DATA,__mod_init_func,mod_init_funcs"

Mach-O requires the S_MOD_INIT_FUNC_POINTERS section flag (mod_init_funcs in link_section). LLVM was accidentally adding this for __DATA,__mod_init_func making it work without explicitly adding ,mod_init_funcs, but I don't know if it guarantees this. See also rust-lang/rustc_codegen_cranelift#1588

[ibraheemdev]

From the Mach-O reference, it looks like mod_init_funcs is not strictly required for the S_MOD_INIT_FUNC_POINTERS to be set. It's possible that this is outdated and retained for backwards compatibility.

S_MOD_INIT_FUNC_POINTERS—This section contains pointers to module initialization functions.
The standard tools create __DATA,__mod_init_funcsections of this type

[RalfJung]

The docs seem to say that S_MOD_INIT_FUNC_POINTERS indicates init functions, which sounds to me like the flag is required to designate a section of init functions?

[ibraheemdev]

I believe the flag is implied on __DATA,__mod_init_func sections, but I'm not sure. LLVM seems to implement it that way and the ecosystem relies on it, so I think it makes sense for Miri to follow.

For this specific test I don't think it matters much whether we specify the flag given that we support it either way, but I can add it if you prefer.

[RalfJung]

If it is questionable whether the version without the extra tag should work (as opposed to "happens to work due to undocumented LLVM accidents"), then at the very least we need a FIXME comment here clarifying this.

the ecosystem relies on it

Do you have a link for that?

[ibraheemdev]

The ctor and inventory crates do not set it explicitly.

I can add a comment to the code. I'm not even sure where to find the official Mach-O reference, all I can find are outdated mirrors.

[bjorn3]

LLVM currently implies the flag for __DATA,__mod_init_func (https://github.com/llvm/llvm-project/blob/2e8e254d18f51b6ca898bf0b1e4d12109b5b16c7/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp#L1292-L1304), but I don't know if it actually guarantees this. The implication is because it creates a section with this name with the flag set somewhere and then merges the attributes of all definitions of the same section.

Edit: llvm/llvm-project@cb307a2 seems to have introduced this behavior as part of moving away from using the .mod_init_func assembly directive which implied this flag.

[RalfJung]

I have added a comment, that should suffice for now -- thanks for the links!

[ibraheemdev]

@rustbot ready

[RalfJung]

Thanks! I'm onboard with the overall architecture, but have a bunch of comments. :)

[RalfJung]

Please avoid rebasing over new commits in master and do not force-push unless there are conflicts. Such rebases cause me a bunch of work since Github is pretty bad at dealing with force-pushes.

[RalfJung]

The docs seem to say that S_MOD_INIT_FUNC_POINTERS indicates init functions, which sounds to me like the flag is required to designate a section of init functions?

[ibraheemdev]

Thanks for pushing this forward!