LTO optimises out conditional code in extern C++ global initialised by mod_init_funcs that's inside mod_init_funcs

[VisualEhrmanntraut]

Enabling LTO silently breaks programs like so:

// A.hpp
extern "C" bool some_external_bool; // comes from dynamic linking

struct A {
    const bool cond;

    A() : cond{some_external_bool} {}
};

extern const A currentA;

// A.cpp

#include "A.hpp"

const A currentA {};

// B.hpp

#include "A.hpp"

struct BConstants {
    unsigned int val;

    B() { this->val = currentA::cond ? 0xDEAD : 0xBEEF; }

    static const BConstants singleton;
};

// B.cpp

#include "B.hpp"

const BConstants BConstants::singleton {};

// main.cpp

#include "B.hpp"
#include <iostream>

int main() {
    std::cout << "val is: " << BConstants::singleton.val << std::endl;
}

Note: Manually typed-out code, may need some adjustments to compile, hopefully not. I was ready to break my keyboard trying to understand why my macOS Kernel Extension was misbehaving, my patience is waning.

Yes, I tried with both Apple Clang and upstream LLVM Clang, it happened with both.

The output will always be 0xBEEF no matter the value of some_external_bool, because LTO is removing the code and replacing it with a constant 0xBEEF.

[keinflue]

The code can't compile like this. Instead of

B() { this->val = currentA::cond ? 0xDEAD : 0xBEEF; }

I assume you mean something like

BConstants() : val(currentA.cond ? 0xDEAD : 0xBEEF) {}

---

The behavior looks valid to me, because the dynamic initialization of BConstants::singleton depends on currentA which also has dynamic initialization, that, because currentA is defined in a different TU, is not ordered with the former's initialization.

This means a valid execution flow is that singleton is initialized before currentA's dynamic initialization happens and then singleton's initialization will read false from currentA.cond's zero-initialized state unconditionally.

This looks like a typical example of the "static initialization order fiasco" and only coincidentally shows up with LTO.

[VisualEhrmanntraut]

The code can't compile like this. Instead of

B() { this->val = currentA::cond ? 0xDEAD : 0xBEEF; }

I assume you mean something like

BConstants() : val(currentA.cond ? 0xDEAD : 0xBEEF) {}

Sorry, I meant no const on the member. The code inside the constructor is correct.

[keinflue]

A solution to this problem is to use function-local static variables instead of global variables with dynamic initialization:

const A& currentA() {
  static const A instance {};
  return instance;
}

//...

BConstants() { this->val = currentA().cond ? 0xDEAD : 0xBEEF; }

//...

static const BConstants& singleton() {
  static const BConstants instance {};
  return instance;
}

//...

std::cout << "val is: " << BConstants::singleton().val << std::endl;

[VisualEhrmanntraut]

I get a error: this initialization requires a guard variable, which the kernel does not support
So this workaround only works on normal programs

[keinflue]

I get a error: this initialization requires a guard variable, which the kernel does not support So this workaround only works on normal programs

In that case you can implement the guard yourself, e.g. assuming there is only single-threaded access to the variable and you do not care about the destructor for A being called on program exit something like (untested):

const A& currentA() {
  alignas(A) static std::byte buffer[sizeof(A)];
  static bool initialized = false;
  if(!initialized) {
    new(buffer) A{};
    initialized = true;
  }
  return *std::launder(reinterpret_cast<A*>(buffer));
}

[VisualEhrmanntraut]

std doesn't exist in the kernel at all 😔 but thanks for the workarounds

[keinflue]

std doesn't exist in the kernel at all 😔 but thanks for the workarounds

std::byte can be replaced by unsigned char and std::launder is kind of fundamental to C++ and you need it to write correct code in certain situations (as are other standard library functions). It is available in Clang as __builtin_launder as well.

(In this case std::launder is technically required by the language specification at the moment, but that might change. It is probably not actually needed for correctness on actual implementations in this situation.)