Re: [PATCH 5/8] LoongArch: fix kernel panic with -fPIC for same-compilation-unit symbol references

[George Guo <dongtai.guo@linux.dev>]

On Fri, 2026-06-05 at 16:10 +0800, Xi Ruoyao wrote:
> This is incorrect.
>
> With GCC and Clang, -fPIC does not mean generating position independent
> code.  It means generating position independent code *suitable for
> SVR4-style shared objects*.
>
> The kernel has nothing to do with SVR4-style shared objects.  The
> kernel modules are not SVR4 shared objects but relocatable ELF object
> files.

You are right, and thank you for the correction. The commit message was
wrong: with CONFIG_RELOCATABLE=y the kernel is already built with -fPIE,
so the reference is not "absolute addressing" as I claimed. I will fix
the description in v2.

> If you only need position independent code (without the shared object
> stuff) you should use -fPIE instead.  The kernel is already built with
> -fPIE if CONFIG_RELOCATABLE=y.
>
> Thus if you only need position independent code you should make live
> patching depend on CONFIG_RELOCATABLE.

This is the part I should have explained better. CONFIG_RELOCATABLE=y is
already set in my config, so the kernel is already -fPIE, and the panic
still happens. I also tried building the KLP objects with -fPIE
explicitly and it does not help -- only -fPIC fixes it.

The reason is not "position independence" but GOT indirection, which is
exactly the SVR4-shared-object behaviour you mention. A minimal
'return uts_sem;' (uts_sem defined in the same TU) compiles like this on
loongarch64 -- same conclusion under both gcc 14.2.1 and clang 19.1.6:

  -fPIE:
    pcalau12i $a0, ...        R_LARCH_PCALA_HI20   uts_sem
    addi.d    $a0, $a0, ...   R_LARCH_PCALA_LO12   uts_sem
    ld.w      $a0, $a0, 0

  -fPIC:
    pcalau12i $a0, ...        R_LARCH_GOT_PC_HI20  uts_sem
    ld.d      $a0, $a0, ...   R_LARCH_GOT_PC_LO12  uts_sem
    ld.w      $a0, $a0, 0

So under -fPIE the access is direct (no GOT); under -fPIC it goes through
the GOT. (As an aside, gcc additionally collapses the -fPIE reference
onto a local anchor .LANCHOR0, leaving no named 'uts_sem' relocation at
all; clang keeps the name but still emits the direct, non-GOT form.)

klp-build extracts the patched function out of its original object file
and links it into a separate livepatch module, while the referenced
symbol (e.g. 'uts_sem') stays in the core kernel. The klp relocation
machinery resolves such cross-object references through GOT entries it
creates in the patch module. The direct R_LARCH_PCALA reference emitted
under -fPIE has no GOT slot for it to fix up, so once the function is
moved into the module its target is wrong and it faults.

So this is one of the cases where the KLP machinery genuinely relies on
the GOT-indirect ("shared object style") access that -fPIC provides and
-fPIE deliberately optimizes away. In v2 I will keep -fPIC but rewrite
the commit message to explain this GOT-vs-direct-PCALA reason instead of
the incorrect "absolute addressing" wording.

I can also include the readelf -r / objdump diff (R_LARCH_PCALA_* under
-fPIE vs R_LARCH_GOT_PC_* under -fPIC) in the v2 commit message if that
is useful.

Thanks again for the review.