LLVM生成共享库时必须加-fPIC，否则链接失败；因其严格遵循ELF规范，要求代码段可重定位、只读且支持ASLR，非PIC代码会破坏共享内存与安全性。
LLVM生成共享库时-fPIC不是可选项，而是ELF加载机制的硬性要求
不加 -fPIC 用LLVM（如 clang）生成 .so 文件，在x86_64 Linux上大概率会链接失败，报错类似：relocation R_X86_64_32 against `myvar' can not be used when making a shared object。这不是LLVM故意设限，而是它严格遵循ELF共享库规范：代码段必须可被多个进程映射到不同虚拟地址，且不能被动态链接器修改。
非PIC代码在共享库中会破坏代码段共享和ASLR安全性
没开 -fPIC 时，编译器生成的指令直接使用绝对地址访问全局变量或跳转到函数，比如 mov eax, DWORD PTR [0x7ffff7abc123]。这种代码一旦被加载到不同基址，就会读错数据、跳错位置。动态链接器只能靠“加载时重定位”来修补——但这就意味着：
- 代码段必须可写（否则无法打补丁），失去只读保护，易被ROP攻击利用
- 每个进程都要维护一份修改后的代码副本，彻底丧失共享内存节省RAM的意义
- 启动时需遍历所有重定位项，拖慢大型程序加载速度
LLVM/Clang对-fPIC的实现依赖RIP相对寻址与GOT/PLT机制
x86_64平台下，clang -fPIC 生成的代码不依赖绝对地址，而是靠CPU原生支持的RIP相对寻址（如 mov rax, QWORD PTR [rip + 0x2009db]）获取GOT表偏移，再通过GOT间接拿到变量真实地址。这个过程完全由编译器+链接器协作完成，运行时无需改写代码段。
关键点：
-
-fPIC不是让LLVM“多做点事”，而是让它放弃生成绝对地址指令，改用符合PIC语义的IR和后端指令序列 - LLVM IR本身不带位置信息，但后端（如X86TargetMachine）在代码生成阶段必须启用PIC模式，否则会输出非RIP-relative的mov/call
- 即使你手写LLVM IR并用
llc生成汇编，最终仍需用clang -shared -fPIC或ld -shared -z text链接，否则GOT/PLT节不会被正确构造
Clang里-fPIC和-fPIE不能混用，尤其别对共享库加-fPIE
有人试过 clang -fPIE -shared 编译so，结果链接时报错或运行时崩溃。根本原因是：-fPIE 假设整个二进制是单进程独占的可执行体，它把全局变量当作“本程序内部固定偏移”处理，而共享库要求变量地址必须能在加载时重定位（即通过GOT）。两者语义冲突。
正确做法只有这一种：
- 生成共享库：始终用
clang -fPIC -shared - 生成PIE可执行文件：用
clang -fPIE -pie（注意是链接时加-pie，不是-shared） - 静态库（
.a）不需要-fPIC，因为它们在链接进主程序时才决定地址
最容易被忽略的是：某些旧版Clang在x86_64上默认开启 -fPIC，让你误以为不加也能成；但换到ARM64或启用LTO后，缺失 -fPIC 就立刻暴露——别依赖默认行为，显式加上最稳。
