解决riscv显式-latomic问题 · Pull Request !263 · src-openEuler/gcc

1. 问题

RISC-V没有1、2字节的原子指令，Gcc截止当前也没有inlining subword atomic函数。为解决这一问题，Gcc通过specs串[将atomic关联到了与其紧密相关的pthread选项](https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/linux.h;h=b9557a75dc72bc451005a8292da9d4829030ba8d;hb=HEAD)，
```
#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC \
  43   " %{pthread:" LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION "}"
```
即有pthread选项时按需链接libatomic.so。但随着Gcc的不断升级优化，很多应用已无需显式给出pthread选项，这就打破了前述努力：当程序需要这些原子操作时，仍要显式-latomic。

2. 解决的方法

riscv社区讨论了很长时间，有建议给Gcc增加内联函数的，但当前还处于[WIP状态](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338)，有建议发行厂商做[workaround](https://github.com/riscv-collab/riscv-gcc/issues/12)，即无条件as-needed -latomic，不再要求pthread这个前置条件；有建议直接针对有需求的各个软件，修改构建过程参数。

这三种方式各有利弊：第一种补丁方式一劳永逸比较理想，但缺少验证，补丁当前也有一些疑问；第三种单包处理方式无风险，但需要逐个包地修改，并且随着软件包升级或打补丁，相应地-latomic取舍可能变化，在GCC和RISC-V彻底解决这个问题后，还要逐个包地修改回来，维护成本很高；第二种无条件as-needed方式基本没有风险，可一劳永逸地解决问题，但由于gcc二阶段构建特点，修改Gcc的specs串[比较困难](https://git.alpinelinux.org/aports/tree/main/gcc/0035-configure-Add-enable-autolink-libatomic-use-in-LINK_.patch)，相当于hack了Gcc的构建过程。

3. 友商做法及我们的建议

openSUSE采用了第一种补丁方式（只查看了它的一个版本），Debian采用了第三种单包处理方式，Alpine和Archlinux采用了第二种方式。其中Archlinux是直接修改了二进制文件中的[specs串](https://github.com/felixonmars/archriscv-packages/blob/master/gcc/riscv64.patch#L82)。

我们建议采用Archlinux的做法（据了解应用效果比较好。），主要考虑它的优点与第一种补丁方式相同，比Alpine的简洁。从原理上来说，虽然hack二进制很“不正规”，但实际作用与objcopy、strip类同，并且修改的是静态串。修改后gcc就依赖了libatomic库，为此增加了gcc主包的Requires。

为验证这种做法的正确性和有效性，在RISC-V架构上用修改后的Gcc编译测试了相关的[8个软件包都成功了](https://build.tarsier-infra.com/project/show/home:laokz:23.03gcc-need-atomic)，打包结果中的Requires正确地按需依赖了libatomic.so。同时也查看了gen_digest_list和build-id有关流程，未发现影响。

修改进行了架构隔离保护，请审核

src-openEuler/gcc .gitee-modal { width: 500px !important; }

搜索帮助

src-openEuler/gcc