关于clang编译内核模块问题

[heiher]

使用clang编译内横模块除了已知的percpu变量访问问题，还发现了一个新的模块访问vmlinux的extern全局变量问题。这两个问题都是因为默认mcmodel下地址编码能力不够导致。

extern全局变量访问问题仅在clang上存在，下面说一下原因。

比如对于如下代码：

extern int a;

int
func (void)
{
    return a;
}

gcc和clang生成的访问方式不同：

1. gcc

• no-pic: R_LARCH_GOT_HI20/LO20
• pic: R_LARCH_GOT_HI20/LO20
• no-pie: R_LARCH_GOT_HI20/LO20
• pie: R_LARCH_GOT_HI20/LO20

2. clang

• no-pic: R_LARCH_PCALA_HI20/LO20
• pic: R_LARCH_GOT_HI20/LO20
• no-pie: R_LARCH_PCALA_HI20/LO20
• pie: R_LARCH_GOT_HI20/LO20

当前上游内核模块编译参数是 no-pic 且 no-pie 的，在访问extern全局变量时，gcc采用got方式，而clang采用pcala方式。后者的地址编码能力不足以从模块空间访问到vmlinux空间。

[heiher]

关于gcc和clang的差异，我个人的看法是：

从代码位置、内容能否改变两点来看，除了内核vmlinux和module这类场景，用户态程序的代码为了能够内存共享一般是不改变内容的，no-pic/no-pie也不改变位置，似乎没有got才能解决问题必要，使用pcala足矣。而pic/pie由于位置也会变化，又因代码只读，故要在可变的got中实施fixup。

那么从这个角度看，是不是clang的实现更合理一些？如果是这样的话，内核的问题建议编译模块加 -fPIC 参数？

有没有比 -fPIC 更轻量的方法呢？@xry111 @xen0n

[xry111]

使用 GOT 就是因为 pcala 的地址编码能力不足以从模块空间访问到 vmlinux 空间。

我之前提过把 vmlinux 从 XKPRANGE 搬到 XKVRANGE (定义见 https://www.kernel.org/doc/html/latest/arch/loongarch/introduction.html#virtual-memory )，但是我自己不会做，也没别人理我：https://lore.kernel.org/lkml/bc323d8578d2f6ec580066bab181788b305ae3c3.camel@xry111.site/

不做这个处理的话，从模块访问 vmlinux 要么用 GOT (-mcmodel=normal)，要么生成多达 5 条指令的全长 la.pcrel 实现 (-mcmodel=extreme -mdirect-extern-access)。前者平均每个寻址使用不超过 16 字节，后者每个寻址必定用 20 字节，所以前者更好。

[xry111]

另外把 vmlinux 搬到 XKVRANGE 还能解除对 model attribute 的依赖：ClangBuiltLinux/linux#1787 (comment)

[heiher]

把vmlinux搬到XKVRANGE理论上是可行的，当然也有代价，vmlinux需要走TLB映射。

[heiher]

RISCV: https://github.com/gcc-mirror/gcc/blob/4169033178f22ff31f2aba186d441bdfeca0e674/gcc/config/riscv/riscv.cc#L803
LoongArch: https://github.com/gcc-mirror/gcc/blob/4169033178f22ff31f2aba186d441bdfeca0e674/gcc/config/loongarch/loongarch.cc#L1840

RISCV限制 flag_pic == true 才生成got方式，这一点与clang/loongarch也是一致的，那么gcc/loongarch是不是应该也加上flag_pic的条件呢。

[xry111]

因为它依赖 copy relocation，而我们没有，以后也不会有。

Maskray 正在试图让 x86_64 和 RISC-V 等架构也停止依赖 copy relocation，因为它会导致一些诡异的问题：https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected

所以试图使用 R_LARCH_COPY 的提交会被 Maskray 直接 NAK。

[xry111]

对于 LoongArch GCC 不想生成 got 就直接 -mdirect-extern-access 就行了，这是个非常简单粗暴的选项。但是正如在上面的回复里面说的，要对 module 用这个选项就要么把 vmlinux 做到 XKVRANGE，要么加 -mcmodel=extreme 然后结果更差。

[heiher]

因为它依赖 copy relocation，而我们没有，以后也不会有。

Maskray 正在试图让 x86_64 和 RISC-V 等架构也停止依赖 copy relocation，因为它会导致一些诡异的问题：https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected

所以试图使用 R_LARCH_COPY 的提交会被 Maskray 直接 NAK。

感谢提供的相关链接，我大概、应该是看明白这里和copy relocation之间的关系了。

这样的话，llvm最好也是像gcc那样对extern全局变量的访问全部生成got访问，再加上direct-extern-access做特定场景的优化。

[xry111]

嘶，如果不对 extern 全局变量做 got 访问的话用 BFD linker 链接出来，那么访问共享库里面的符号是爆炸的。比如就这个东西：

extern char **environ;

int main()
{
  __builtin_printf("%10s\n", environ[0]);
}

如果强行开 -mdirect-extern-access，结果会 bus error。objdump -d 一下发现加载 environ 的指令序列是：

 640:	1a00000c 	pcalau12i   	$t0, 0
 644:	02d7818c 	addi.d      	$t0, $t0, 1504
 648:	2600018c 	ldptr.d     	$t0, $t0, 0

然后 1504 (0x5e0) 这个地方是啥呢，是：

00000000000005e0 <environ@plt>:
 5e0:	1c00010f 28e8c1ef 4c0001ed 03400000     .......(...L..@.

你看这个 @plt 应该能猜到链接器干了什么蠢事罢 (人家其他架构的链接器看到这种要么用 copy relocation，要么直接报错)…… 这个蠢事就是用 R_LARCH_PCALA_LO12 作用在 jirl 上实现旧的 medium code model 的恶果。最新的 psABI 要求改用 R_LARCH_CALL36 做 medium code model 了，但是为了“向后兼容性”这个蠢事还是不太好改 :(。

说回主题，难道 lld 链接这个东西不爆炸？那估计 lld 用了 copy relocation (难道没被 Maskray 骂) 或者别的什么高论？

[heiher]

哈哈，编内核模块静态链接时没炸，加载模块时也没炸，执行到访问时当然就炸啦~

[MQ-mengqing]

之前mold链接炸了。原因是R_LARCH_PCALA_HI20会区分是外部的还是内部，是外部的直接拿去当plt，mold当时没有整就炸了。现在binutils，mold都是处理外部符号HI20当plt，lld可能是和LO12的处理有关导致链接没有炸。

[heiher]

更新一下进展：

clang也有类似gcc的direct-extern-access选项（maskray加的），与gcc的不同之处在于，当 no-pic 或 no-pie 时，clang的 direct-access-external-data 默认开启。现在解决方法是让模块关闭从而走GOT方式访问：

diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
index fb0fada43197..c31a62521e6b 100644
--- a/arch/loongarch/Makefile
+++ b/arch/loongarch/Makefile
@@ -68,6 +68,8 @@ LDFLAGS_vmlinux                       += -static -n -nostdlib
 ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS
 cflags-y                       += $(call cc-option,-mexplicit-relocs)
 KBUILD_CFLAGS_KERNEL           += $(call cc-option,-mdirect-extern-access)
+KBUILD_AFLAGS_MODULE           += $(call cc-option,-fno-direct-access-external-data)
+KBUILD_CFLAGS_MODULE           += $(call cc-option,-fno-direct-access-external-data)
 KBUILD_AFLAGS_MODULE           += $(call cc-option,-mno-relax) $(call cc-option,-Wa$(comma)-mno-relax)
 KBUILD_CFLAGS_MODULE           += $(call cc-option,-mno-relax) $(call cc-option,-Wa$(comma)-mno-relax)
 else

[heiher]

clang code-model=large 与 gcc code-model=extreme 不一致的地方：

代码：

#ifdef __clang__
extern __attribute__((model("large"))) __typeof__(int) pcpu;
#else
extern __attribute__((model("extreme"))) __typeof__(int) pcpu;
#endif

int fun(void)
{
    return pcpu;
}

GCC：

gcc -O2 -c -o t.o t.c
llvm-objdump -r t.o

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE                     VALUE
0000000000000000 R_LARCH_GOT_PC_HI20      pcpu
0000000000000004 R_LARCH_GOT_PC_LO12      pcpu

Clang：

clang -target loongarch64 -O2 -c -o t.o a.c -fno-direct-access-external-data
llvm-objdump -r t.o

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE                     VALUE
0000000000000000 R_LARCH_GOT_PC_HI20      pcpu
0000000000000004 R_LARCH_GOT_PC_LO12      pcpu
0000000000000008 R_LARCH_GOT64_PC_LO20    pcpu
000000000000000c R_LARCH_GOT64_PC_HI12    pcpu

差异是访问自己链接单元的GOT是否使用64位模式。从GCC的-mcmodel文档来看，extreme高于large，那么是GCC实现的小了，还是Clang的实现大了？

[xry111]

访问自己链接单元的 GOT 不受 model attribute 影响，因为 GOT 是一整个 section，不存在单独某个符号的 GOT entry 出了正负 2GB 的情况。如果 GOT 出了正负 2GB 应该直接用 -mcmodel=extreme 而不应该用 model attribute。

给 per-cpu 符号加 model attribute 是针对同一 TU 中的引用，就是 pcrel 方式的引用要用 64 位模式。其实用 GOT 和 32 位模式也行 (就跟访问 extern 的符号一样)，但是 GCC 方面的讨论我记得是不建议加一个强制用 GOT 访问的 attribute。

[heiher]

妙呀，llvm的实现稍加修改即可。

[heiher]

搞定，内核又可以少一个增加GOT64_PC重定位的补丁。感谢提示 👍

[xen0n]

ClangBuiltLinux/linux#1884 was resolved a while ago, closing. 🎉