On Mon, Jun 08, 2026 at 06:08:46PM +0800, George Guo wrote:
> From: George Guo <[email protected]>
>
> objtool needs to split the kernel's special sections into per-entry
> symbols when generating livepatch modules. Mark them so it can:
>
> - .altinstructions and __ex_table are read-only, so set an explicit
> entry size via SHF_MERGE (ALT_INSTR_SIZE / EXTABLE_SIZE).
>
> - __bug_table and __jump_table are writable. SHF_MERGE cannot be
> combined with SHF_WRITE (Clang rejects it), so annotate each entry
> with ANNOTATE_DATA_SPECIAL instead, mirroring x86/arm64.
>
> Co-developed-by: Kexin Liu <[email protected]>
> Signed-off-by: Kexin Liu <[email protected]>
> Signed-off-by: George Guo <[email protected]>
> ---
Hi George,
Disclaimer: I don't have LoongArch hardware, so the best I can do with
this patchset is to read and poke at it with (cross) compilation.
For the special sections, said cross compiler (loongarch64-linux-gnu-gcc
(GCC) 15.2.1 20250808 (Red Hat Cross 15.2.1-1)) is interesting as it
appears to emit relocs in special sections (__ex_table,
.altinstructions, __bug_table, __jump_table) that point to local
assembler labels in the function's text section rather than the section
symbol + offset.
An example gcc / loongarch .rela__ex_table section looks like:
Relocation section '.rela__ex_table' at offset 0x6a28 contains 10 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
0000000000000000 0000005d00000063 R_LARCH_32_PCREL 00000000000011f0
.L1^B4 + 0
0000000000000004 0000005e00000063 R_LARCH_32_PCREL 00000000000011f4
.L2^B1 + 0
[ ... snip ... ]
Unlike everywhere else ...
llvm / loongarch:
Relocation section '.rela__ex_table' at offset 0x5710 contains 10 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
0000000000000000 0000000200000063 R_LARCH_32_PCREL 0000000000000000
.text + 2a70
0000000000000004 0000000200000063 R_LARCH_32_PCREL 0000000000000000
.text + 2a74
gcc / x86:
Relocation section '.rela__ex_table' at offset 0x40f50 contains 2 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
0000000000000000 0000000200000002 R_X86_64_PC32 0000000000000000
.text + 1596
0000000000000004 0000000200000002 R_X86_64_PC32 0000000000000000
.text + 159b
llvm / x86:
Relocation section '.rela__ex_table' at offset 0x343d8 contains 2 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
0000000000000000 0000000200000002 R_X86_64_PC32 0000000000000000
.text + 231a
0000000000000004 0000000200000002 R_X86_64_PC32 0000000000000000
.text + 231f
gcc / aarch64:
Relocation section '.rela__ex_table' at offset 0x448c8 contains 10 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
0000000000000000 0000000200000105 R_AARCH64_PREL32 0000000000000000
.text + 24bc
0000000000000004 0000000200000105 R_AARCH64_PREL32 0000000000000000
.text + 2524
[ ... snip ... ]
llvm / aarch64 Relocation section '.rela__ex_table' at offset 0x37760 contains
10 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
0000000000000000 0000000200000105 R_AARCH64_PREL32 0000000000000000
.text + 2730
0000000000000004 0000000200000105 R_AARCH64_PREL32 0000000000000000
.text + 264c
[ ... snip ... ]
The objtool/klp-diff.c implications is that
convert_reloc_secsym_to_sym() doesn't handle such non-section symbol
relocs in special sections:
if (!is_sec_sym(sym))
return 0;
That early return leaves the reloc pointing at a .L* symbol that is
never cloned into the output livepatch object. When
clone_special_section() later calls should_keep_special_sym() to decide
whether to include each table entry, it cannot map the reloc to an
included function and silently drops it. In the __ex_table case above,
the patched function's entries are missing from the .ko. As far as I
can tell, this problem applies to other special sections (like
.altinstructions, etc.) as well.
If not GCC / GAS is to be supported, then klp-diff will need to handle
this alternate relocation format. Perhaps these could be pre-converted
in convert_reloc_secsym_to_sym() to the general form (func_sym +
(label_offset - func_offset)) that is expected? I don't know if that's
enough to keep everything hanging together, but might be a place to
start.
--
Joe
