RISC-V miscompilation: Clang misaligns kprobe test arrays or omits labels, causing Linux kernel KUnit failures (GNU as works)

[j1akai]

Summary (Miscompilation)

This is a miscompilation issue:

The compiler successfully produces an executable Linux kernel Image, but the kernel does not run correctly.

When compiling the Linux RISC-V kernel with Clang, the kernel boots but crashes during KUnit kprobes selftests due to corrupted data in test_kprobes_addresses[] and test_kprobes_functions[]. The same kernel built with GCC does not exhibit the issue.

I suspect this is caused by Clang misaligning .rodata arrays or failing to emit local labels that are referenced later as symbols.

Environment

• Clang version used:
  https://github.com/llvm/llvm-project/releases/download/llvmorg-21.1.5/LLVM-21.1.5-Linux-X64.tar.xz
• Linux kernel version:
  https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/snapshot/linux-riscv-for-linus-6.18-rc6.tar.gz
• Target: riscv64

Observed Behavior

The kernel builds successfully with Clang, producing a valid Image.
However, when booted under QEMU, it fails during initialization of the RISC-V KUnit kprobes tests:

Log:
https://github.com/j1akai/temp/blob/main/20251113/report0.log

The root cause appears to be that the linker-visible arrays:

• test_kprobes_addresses[]
• test_kprobes_functions[]

defined in:

arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S

are corrupted when assembled with Clang, but correct when assembled with riscv64-linux-gnu-as.

This eventually leads to:

num_kprobe is overestimated
kcalloc() attempts to allocate an excessively large block
allocation fails -> KUnit fails

Analysis

Details:
https://github.com/j1akai/temp/blob/main/20251113/readme.md

Summary of findings:

1. Clang does not emit local labels unless explicitly marked .globl

test_kprobes_add_addr1: and similar labels inside functions do not appear as symbols unless manually marked .globl.

GNU as does emit these labels, so RISCV_PTR label produces valid addresses.

With Clang, many entries in test_kprobes_addresses[] become:

• 0x0000000000000000
• uninitialized memory
• garbage values

This corrupts the array.

---

2. Clang aligns and places .rodata differently

Even with identical assembly:

.section .rodata
RISCV_PTR test_kprobes_add_addr1
RISCV_PTR test_kprobes_add_addr2
...

GNU as guarantees:

• 8-byte alignment for pointer arrays
• placement in .rodata

Clang sometimes:

• does not align the array at 8 bytes unless .align 3 is added
• places it in .data if attributes are missing
• produces a larger-than-expected section that confuses the kernel logic

This causes:

test_kprobes_addresses[] appears larger than it actually is
while (test_kprobes_addresses[num_kprobe]) runs past the end
leading to invalid memory accesses

Linux community discussion

I reported this issue to the Linux RISC-V community; the maintainers recommended seeking the LLVM community's opinion on this behavior so they can decide whether to accept a workaround in the kernel. See the Linux discussion:

• https://lists.infradead.org/pipermail/linux-riscv/2025-November/080819.html
• https://lists.infradead.org/pipermail/linux-riscv/2025-November/080950.html

Thank you for taking the time to read this issue.

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: None (j1akai)

## **Summary (Miscompilation)**

This is a miscompilation issue:

> The compiler successfully produces an executable Linux kernel Image, but the kernel does not run correctly.

When compiling the Linux RISC-V kernel with Clang, the kernel boots but crashes during KUnit kprobes selftests due to corrupted data in test_kprobes_addresses[] and test_kprobes_functions[]. The same kernel built with GCC does not exhibit the issue.

I suspect this is caused by Clang misaligning .rodata arrays or failing to emit local labels that are referenced later as symbols.

Environment

• Clang version used:
  https://github.com/llvm/llvm-project/releases/download/llvmorg-21.1.5/LLVM-21.1.5-Linux-X64.tar.xz
• Linux kernel version:
  https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/snapshot/linux-riscv-for-linus-6.18-rc6.tar.gz
• Target: riscv64

Observed Behavior

The kernel builds successfully with Clang, producing a valid Image.
However, when booted under QEMU, it fails during initialization of the RISC-V KUnit kprobes tests:

Log:
https://github.com/j1akai/temp/blob/main/20251113/report0.log

The root cause appears to be that the linker-visible arrays:

• test_kprobes_addresses[]
• test_kprobes_functions[]

defined in:

arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S

are corrupted when assembled with Clang, but correct when assembled with riscv64-linux-gnu-as.

This eventually leads to:

num_kprobe is overestimated
kcalloc() attempts to allocate an excessively large block
allocation fails -> KUnit fails

Analysis

Details:
https://github.com/j1akai/temp/blob/main/20251113/readme.md

Summary of findings:

1. Clang does not emit local labels unless explicitly marked .globl

test_kprobes_add_addr1: and similar labels inside functions do not appear as symbols unless manually marked .globl.

GNU as does emit these labels, so RISCV_PTR label produces valid addresses.

With Clang, many entries in test_kprobes_addresses[] become:

• 0x0000000000000000
• uninitialized memory
• garbage values

This corrupts the array.

---

2. Clang aligns and places .rodata differently

Even with identical assembly:

.section .rodata
RISCV_PTR test_kprobes_add_addr1
RISCV_PTR test_kprobes_add_addr2
...

GNU as guarantees:

• 8-byte alignment for pointer arrays
• placement in .rodata

Clang sometimes:

• does not align the array at 8 bytes unless .align 3 is added
• places it in .data if attributes are missing
• produces a larger-than-expected section that confuses the kernel logic

This causes:

test_kprobes_addresses[] appears larger than it actually is
while (test_kprobes_addresses[num_kprobe]) runs past the end
leading to invalid memory accesses

Linux community discussion

I reported this issue to the Linux RISC-V community; the maintainers recommended seeking the LLVM community's opinion on this behavior so they can decide whether to accept a workaround in the kernel. See the Linux discussion:

• https://lists.infradead.org/pipermail/linux-riscv/2025-November/080819.html
• https://lists.infradead.org/pipermail/linux-riscv/2025-November/080950.html

Thank you for taking the time to read this issue.

[topperc]

@kito-cheng can you confirm what guarantees GNU as makes?

[kito-cheng]

GNU as guarantees:
8-byte alignment for pointer arrays
placement in .rodata

I don't see this guarantee from the binutils source code or document, so adding explicitly .align is necessary I think, also I checked SYM_DATA_START, it's also not specify alignment as well.

Also explicitly specify that in rodata is good, I didn't full build the kernel but just assemble that file, then I saw both compiler/toolchain are put that into all thing into text section since it's not specify the section info.

Last, specify .globl to resolve this issue seems not reasonable to me...it should be able to relocate correctly no matter the symbol is local or global.

[kito-cheng]

@MaskRay might have more insight on this issue.

[MaskRay]

GNU as guarantees:
8-byte alignment for pointer arrays
placement in .rodata

I don't see this guarantee from the binutils source code or document, so adding explicitly .align is necessary I think, also I checked SYM_DATA_START, it's also not specify alignment as well.

Also explicitly specify that in rodata is good, I didn't full build the kernel but just assemble that file, then I saw both compiler/toolchain are put that into all thing into text section since it's not specify the section info.

Last, specify .globl to resolve this issue seems not reasonable to me...it should be able to relocate correctly no matter the symbol is local or global.

Agreed with the analysis. GNU Assembler doesn't have the alignment guarantee.

.align should be generally avoided as the value may or may not mean a power of 2 (arch-dependent behavior). Use .p2align 3 and .balign 8

test_kprobes_add_addr1: and similar labels inside functions do not appear as symbols unless manually marked .globl.

f: defines a STB_LOCAL symbol while .globl f; f: defines a STB_GLOBAL symbol.

Can you investigate why the symbol binding changes the behavior? There are probably relocation differences. I suspect that the kernel assembly is using something not guaranteed by assemblers.

[covanam]

I narrowed down the issue. .globl doesn't matter. Alignment also does not matter. But moving the arrays to .rodata somehow fixes the problem.

Some background about this array: The riscv kernel supports relocation, meaning the kernel reads the relocation records at run-time and relocates itself. This is the array which needs relocated:

SYM_DATA_START(test_kprobes_addresses)
	RISCV_PTR test_kprobes_add_addr1
	RISCV_PTR test_kprobes_add_addr2
	RISCV_PTR test_kprobes_jal_addr1
	RISCV_PTR test_kprobes_jal_addr2
        ...

(source)

What I found is that the relocation records are wrong:

# riscv64-linux-gnu-objdump -R vmlinux
vmlinux:     file format elf64-littleriscv

DYNAMIC RELOCATION RECORDS
OFFSET           TYPE              VALUE
ffffffff8000f4aa R_RISCV_RELATIVE  *ABS*-0x000000007fff0cc0 # test_kprobes_add_addr1 
ffffffff8000f4b2 R_RISCV_RELATIVE  *ABS*-0x000000007fff0cbe # test_kprobes_add_addr2
ffffffff8000f4ba R_RISCV_RELATIVE  *ABS*-0x000000007fff0cb4 # test_kprobes_jal_addr1
ffffffff8000f4c2 R_RISCV_RELATIVE  *ABS*-0x000000007fff0ca4 # test_kprobes_jal_addr2

The relocation record says relocate at address 0xffffffff8000f4aa and so on. But this is not the correct address of the array. The correct address is 0xffffffff8000f4a4. For unclear reason, the relocation records are 6 byte off.

# riscv64-linux-gnu-nm vmlinux
...
ffffffff8000f334 T test_kprobes_add
ffffffff8000f340 t test_kprobes_add_addr1
ffffffff8000f342 t test_kprobes_add_addr2
ffffffff8000f4a4 T test_kprobes_addresses
ffffffff8000f38c T test_kprobes_auipc
ffffffff8000f38c t test_kprobes_auipc_addr
...

As the kernel relies on this relocation record, it relocates itself wrongly and thus is broken.

For unclear reason, by moving the arrays to .rodata with this patch:

diff --git a/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S b/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S
index b951d0f12482..f16deee9e091 100644
--- a/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S
+++ b/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S
@@ -181,6 +181,7 @@ SYM_FUNC_END(test_kprobes_c_bnez)
 
 #endif /* CONFIG_RISCV_ISA_C */
 
+.section .rodata
 SYM_DATA_START(test_kprobes_addresses)
        RISCV_PTR test_kprobes_add_addr1
        RISCV_PTR test_kprobes_add_addr2
@@ -212,6 +213,7 @@ SYM_DATA_START(test_kprobes_addresses)
        RISCV_PTR 0
 SYM_DATA_END(test_kprobes_addresses)
 
+.section .rodata
 SYM_DATA_START(test_kprobes_functions)
        RISCV_PTR test_kprobes_add
        RISCV_PTR test_kprobes_jal

Then the relocation records are all correct:

# riscv64-linux-gnu-objdump -R vmlinux
vmlinux:     file format elf64-littleriscv

DYNAMIC RELOCATION RECORDS
OFFSET           TYPE              VALUE
...
ffffffff81201428 R_RISCV_RELATIVE  *ABS*-0x000000007fff0cc0 # test_kprobes_add_addr1
ffffffff81201430 R_RISCV_RELATIVE  *ABS*-0x000000007fff0cbe # test_kprobes_add_addr2
ffffffff81201438 R_RISCV_RELATIVE  *ABS*-0x000000007fff0cb4 # test_kprobes_jal_addr1
ffffffff81201440 R_RISCV_RELATIVE  *ABS*-0x000000007fff0ca4 # test_kprobes_jal_addr2

as the relocation records now have the correct address (0xffffffff81201428) of test_kprobes_addresses.

# riscv64-linux-gnu-nm vmlinux
...
ffffffff8000f340 t test_kprobes_add_addr1
ffffffff8000f342 t test_kprobes_add_addr2
ffffffff81201428 D test_kprobes_addresses
ffffffff8000f38c T test_kprobes_auipc
ffffffff8000f38c t test_kprobes_auipc_addr

Moving the array to .rodata is something we should do regardless. But I am still curious why does that fix the problem.

What I also observed is that compared to the initial object file, the final linked image is missing a few NOP instructions. Therefore, I am speculating that perhaps the linker is removing NOPs for whatever reason, but then forgets to update the relocation records to match the new offsets. I'm thinking maybe the linker only update the relocation records for .rodata section, but forget about .text section. But I don't know enough about compilers to investigate this idea further.

To summary, my questions are:

• Why are the dynamic relocation records wrong?
• Why moving the arrays to .rodata fixes the dynamic relocation records?

[covanam]

@nathanchance posted his analysis on kernel mailing list (which includes a reproducer). This may be useful:
https://lore.kernel.org/linux-riscv/20251119013808.GA1264583@ax162/

[lenary]

Is there output about relaxation from the linker? I recall this old issue about ifuncs which suggests there could still be bugs lurking in LLD? I'm not sure. I don't think the kernel has ifuncs but maybe there's a similar underlying cause

#99660

[jrtc27]

Is this not just as simple as "RISCV::finalizeRelax adjusts the static relocations but not dynamic ones"? Presumably it doesn't adjust dynamic ones because there is the expectation that you're not using text relocations (I think it might even be forbidden with RISC-V glibc? but perhaps remembering something else), but in this case the kernel is (gratuitously?) using text relocations.