Messages in this thread | | | From | Nick Desaulniers <> | Date | Thu, 18 Apr 2024 08:44:12 -0700 | Subject | Re: [PATCH 0/2] x86/purgatory: Avoid kexec runtime warning with LLVM 18 |
| |
On Thu, Apr 18, 2024 at 4:15 AM Borislav Petkov <bp@alien8.de> wrote: > How much of this silliness should we expect now for other parts of the kernel?
Looks like ARCH=powerpc sets -mcmodel=large for modules and ARCH=um does for the whole kernel. So that LLVM change may have implications for those 2 other architectures. Not sure we've had any bug reports or breakage in CI yet, like we have for x86+kexec.
> Can we turn this off?
Maybe we need to revisit commit e16c2983fba0 ("x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors")
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e16c2983fba0fa6763e43ad10916be35e3d8dc05
at least the -mcmodel=kernel addition (since that patch added a few additional compiler flags that still LGTM).
> Why does llvm enforce .ltext for large code models and why gcc doesn't do that? Why does llvm need to do that, what requirement dictates that?
Google is now at the point where a few binaries running in data centers are measured in the gigabytes, and attempting to link them may result in relocation overflows. From that commit message, it sounds like they link together object files built with the default code model and some objects from the larger code model. Putting large code model data+code in distinct sections is helpful for then being able to place those further away in an object. For other architectures, the linker may insert a veneer/trampoline. Not sure why that's not used here.
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mlarge-data-threshold makes it sound like GCC may place data larger than a certain threshold in a new section. Dunno about code (.text) though.
Arthur, you probably happen to know more about code models at this point than anyone particularly cares to. The raison d'etre for e16c2983fba0 was avoiding R_X86_64_32/R_X86_64_32S relocations. Do you know if there's another code model that can force R_X86_64_64? Or is the large code model the way to go here, with updates to linker scripts for this new section?
+ Fangrui, Ard, who might know of alternative solutions to -mcmodel=large for e16c2983fba0.
Otherwise, I think the dedicated linker script is the way to go. We really want tight control over what is or is not in the purgatory image. -- Thanks, ~Nick Desaulniers
| |