Link errors when mixing code models

[palmer-dabbelt]

I'm not sure if this is actually new, but it's the first time I've seen it: https://lore.kernel.org/all/202506290255.KBVM83vZ-lkp@intel.com/

   ld.lld: error: Function Import: link error: linking module flags 'Code Model': IDs have conflicting values: 'i32 3' from vmlinux.a(init.o at 899876), and 'i32 1' from vmlinux.a(net-traces.o at 1014596)

IMO this shouldn't be a link error. There's a comment saying

// Linking object files with different code models is undefined behavior
// because the compiler would have to generate additional code (to span
// longer jumps) if a larger code model is used with a smaller one.
// Therefore we will treat attempts to mix code models as an error.

but I don't agree with that. The code model determines which relocations should be emitted, there's easily definable behavior if all those relocations can be resolved (just link it and it runs fine) and if any of those relocations can't be resolved (emit a truncation error). That's the same behavior regardless of mixing code models, I don't see any object-wide behavior related to which code model is used. So I don't see where the UB creeps in.

That said, as far as I can tell this has been there since 2018 and we're just starting to see the errors now. I'd also expect this to trip up all over the place, so not sure what I'm missing.

[nathanchance]

cc @MaskRay for LLVM / ld.lld expertise. It is my understanding that this is related to LTO based on the change that introduced this error:

llvm/llvm-project@3dea3f9

There was some discussion of this during code review that I can see on Phabricator but I do not really understand it either.

https://reviews.llvm.org/D52322

This is only triggered with CONFIG_CMODEL_MEDLOW if I understand correctly, as there are some files built with -mcmodel=medany, causing the mismatch. We could avoid this by only allowing LTO with CONFIG_CMODEL_MEDANY:

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 1d49de27ec1a..87afab8bcce8 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -64,7 +64,7 @@ config RISCV
        select ARCH_SUPPORTS_HUGE_PFNMAP if TRANSPARENT_HUGEPAGE
        select ARCH_SUPPORTS_HUGETLBFS if MMU
        # LLD >= 14: https://github.com/llvm/llvm-project/issues/50505
-       select ARCH_SUPPORTS_LTO_CLANG if LLD_VERSION >= 140000
+       select ARCH_SUPPORTS_LTO_CLANG if LLD_VERSION >= 140000 && CMODEL_MEDANY
        select ARCH_SUPPORTS_LTO_CLANG_THIN if LLD_VERSION >= 140000
        select ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS if 64BIT && MMU
        select ARCH_SUPPORTS_PAGE_TABLE_CHECK if MMU

[MaskRay]

During LLVM LTO, IR generation and object file generation are distinct phases. To pass information to the object file generation phase, three main approaches are used:

• Store the information as module flags metadata during IR generation.
• Store the information as function or variable attributes during IR generation.
• Skip actions in the IR generation phase and have Clang pass an -mllvm option to the linker.

Each approach has its advantages and drawbacks, with no single method being clearly superior.

In https://reviews.llvm.org/D52322 , the module flags metadata approach was chosen, with errors reported for conflicting values.
This conservative approach ensures clarity when linking object files with different code models.
I can think of both scenarios: when users want the smaller model, and when users want the larger model.

As noted, the behavior hasn't changed since 2018.

[nathanchance]

Alright, thanks a lot for that information. I think it makes sense to send my diff above to avoid this then. Other places where we have hit this in the kernel were able to filter out $(CC_FLAGS_LTO) but I think that would be unmaintainable in this case because of how many files use an explicit -mcmodel=medany.

[nathanchance]

Patch formally submitted: https://lore.kernel.org/20250710-riscv-restrict-lto-to-medany-v1-1-b1dac9871ecf@kernel.org/