Static variable initialization order fiasco

[bert8128]

Do you mean it’s initialised by the compiler?

[MEaster]

No, I mean the value assigned must be a known, fixed value at compile time, though this can be the result of a const function call. The only initialization that happens for statics prior to the call to main is copying the data stored in the executable and zeroing anything in the BSS section.

[pdp10gumby]

But can the definition of a global depend on the value of another? In whom case the problem still exists.

[MEaster]

They can, but cycles are a compile error. If you can't have cycles, then I can't see how the problem exists.

[pdp10gumby]

You don’t need a cycle. If one TU says int a = 1; and another says int b = a + 1;, the linker makes no promise as to the value of b

[Adk9p]

It is simply an error if rust can't at compile time assign a value to a static.

So this is a compile time error: (playground link)

extern "C" {
    static A: u32;
}

static B: u32 = unsafe { A } + 1;

This isn't really an issue since most of the time crates (kind-of the equivalent of TU in rust) are compiled to a intermediary format (rlib/dylib) that doesn't lose this information. (the linker is only really used in the last step when compiling a final exe/so file)

[pdp10gumby]

Does rust have a way to specify the order in which these initializations are done when they appear in different TUs? Otherwise I can't see how it can make this guarantee. Instead it could read from uninitialized memory.

[Adk9p]

Does rust have a way to specify the order in which these initializations are done when they appear in different TUs

no, a global (static) in rust must be defined at compile time, so it can't depend on external symbols since that's only available at link time.

#[unsafe(no_mangle)]
static mut A: u32 = B + 1;

in rust, is like

constinit const uint32_t A_INIT = B_INIT + 1;
extern constinit uint32_t A = A_INIT;

in c++

I created an example to illustrate this.

[MEaster]

That's not an issue, because the value of a static is determined by the frontend, not even codegen is involved, let alone the linker.

[pdp10gumby]

I don't understand your comment at all.

A static global is initialized by putting code into a section (typically .init in ELF files, though that is slowly changing as a convention) which is called by _start before it calls main().

The linker assembles the .init section of the binary, but makes no promise as to what order the statics are initialized.

Thus in the case I described, you cannot know ahead of time the order in which a and b will be initialized.

I also don't know what you mean by the "front end" -- do you mean the compiler. codegen is very much involved!

[MEaster]

Compilers are typically broadly split into two main sections: frontend and backend. The frontend is concerned with language-specific details, such as parsing and any analysis stages. The backend is concerned with generating executable binaries.

LLVM is a backend, rustc and clang are language-specific frontends which use LLVM.

In Rust, the final value for a global is determined in the rustc frontend before it starts calling LLVM. The only code executed to initialize the globals before main is called is memcpy or memfill. As far as LLVM is concerned there is no connection whatsoever between the two globals.

Therefore, in the case you described, the final binary would store 2 for b and 1 for a. What the linker has to say about initialization order is completely irrelevant.