Re: [PATCH v2 0/8] LoongArch: Add livepatch build (KLP) support

Hi Joe,=0D
Thanks for reviewing!=0D
=0D
> Ok, what am I doing wrong here:=0D
[...]=0D
> What compiler / kernel config should I be trying with this patchset?=0D
=0D
Nothing wrong on your side -- both things you hit are real bugs, thanks=0D
for running the full flow.  Fixes for both (and for the special-section=0D
reloc issue you reported earlier) are queued for v3.  Quick answers to=0D
the compiler/config question:=0D
=0D
Compiler:=0D
=0D
 - GCC: this is what the series was tested with, on real LoongArch=0D
   hardware (livepatch modules generated, loaded and exercised).=0D
 - LLVM: your clang 21 is fine.  Note that klp-build itself requires=0D
   the LLVM assembler >=3D 20.=0D
=0D
Config:=0D
=0D
 - defconfig plus your script is exactly right.=0D
 - The FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY select you added is=0D
   the proper fix, not a workaround: arch/loongarch/Makefile already=0D
   builds with -fpatchable-function-entry=3D2.  v3 adds exactly that as=0D
   a patch, with your Reported-by/Suggested-by if that's ok with you.=0D
=0D
On the "duplicate reloc" error: reproduced and fixed.  The key field=0D
of a __jump_table entry is a cross-section difference (".quad key - ."),=0D
and clang's integrated assembler emits it as a relocation pair at the=0D
same offset when the key is not defined in the same translation unit:=0D
=0D
  $ readelf -rW net/core/dev.o        # clang 21.1.8=0D
  0x18  R_LARCH_ADD64  __tracepoint_netif_rx + 8=0D
  0x18  R_LARCH_SUB64  __jump_table + 0x18=0D
=0D
Locally-defined keys (e.g. netstamp_needed_key) get a single=0D
R_LARCH_64_PCREL instead, and GAS emits the single form in both cases,=0D
which is why a GCC build never trips on this.  objtool's=0D
elf_create_reloc() allows only one relocation per offset, so cloning=0D
such an entry fails on the SUB half.=0D
=0D
The fix queued for v3 folds the pair into the single equivalent=0D
R_LARCH_64_PCREL (which the module loader already supports).  With it,=0D
your exact test.patch now builds cleanly here with clang 21.1.8 on=0D
LoongArch hardware; the tracepoint key correctly ends up as a klp=0D
relocation against .klp.sym.vmlinux.__tracepoint_netif_rx.=0D
=0D
Thanks,=0D
George=0D