Fix toolchain conventions and psABI document. #25

scylaac · 2021-11-04T09:34:03Z

No description provided.

ChenghuaXu

可以，先有一个基本框架，里面个别有争议的内容，通过单独的pr来讨论修改。

xen0n · 2021-11-04T09:47:15Z

docs/LoongArch-toolchain-conventions-CN.adoc

@@ -199,7 +200,7 @@ v1.00 定义的指令集架构

 原则上，实际配置的目标架构不应该对目标 ABI 的确定造成影响，
 除非构建时配置或命令行选项对 ABI 的约束导致实现它所需的指令集特性
-超出了编译选项对 ISA 配置的约束范围。此时编译器应报错退出。
+超出了编译选项对 ISA 配置的约束范围。此时编译器可选择报错退出。


建议明确指定 不报错时候的预期行为 为何

补充：明确冲突的情况确实应该报错退出。

如果 ABI 用的是默认配置，这里就不限制预期行为了。可以报错，也可以按需"降级" ABI（例如在默认 ABI 为 lp64d 的编译器上用 -mfpu=32），但这个逻辑比较复杂，只是目前对GCC的一个设想（用户有这种意图的时候也许应该显式给出 -mabi，或者直接用 -msingle-float ）。

嗯，诸如此类的解释性文字一般都可以加入规范文本中，作为有益的、建议性质的语义澄清与补充。个人经验。

FreeFlyingSheep · 2021-11-04T09:50:29Z

英文版漏了 [[isa-modules]]。

yetist · 2021-11-04T09:54:03Z

可以，先有一个基本框架，里面个别有争议的内容，通过单独的pr来讨论修改。

社区的做事风格一般是PR有待定、部分问题未达成一致，则整个PR就会一直开着，直到完全修改好才合并；或者修改PR，仅提交达成一致的内容，其他问题在新PR中继续讨论。

xen0n

#24 中剩余的几个问题：

v0/v1/fv0/fv1 的具体处理细节；
裸的 char 有无符号的提示文字；
带版本的 -march 取值；
-march -mtune 取值上未来添加变换的可能性，处理方式；
_LOONGARCH_XXX 命名风格不一致的符号的处理；
ABI flag 表格的排序。

xen0n · 2021-11-04T11:04:25Z

docs/LoongArch-ELF-ABI-CN.adoc

-|/lib64/ld-linux-loongarch-lp64d.so.<abiversion>
+|/lib64/ld-linux-loongarch-lp64d.so.1

 |lp64f                |default
 |Linux, Glibc
-|/lib64/ld-linux-loongarch-lp64f.so.<abiversion>
+|/lib64/ld-linux-loongarch-lp64f.so.1

 |lp64s                |default
 |Linux, Glibc
-|/lib64/ld-linux-loongarch-lp64s.so.<abiversion>
+|/lib64/ld-linux-loongarch-lp64s.so.1

 |ilp32d               |default
 |Linux, Glibc
-|/lib32/ld-linux-loongarch-ilp32d.so.<abiversion>
+|/lib32/ld-linux-loongarch-ilp32d.so.1

 |ilp32f               |default
 |Linux, Glibc
-|/lib32/ld-linux-loongarch-ilp32f.so.<abiversion>
+|/lib32/ld-linux-loongarch-ilp32f.so.1

 |ilp32s               |default
 |Linux, Glibc
-|/lib32/ld-linux-loongarch-ilp32s.so.<abiversion>
+|/lib32/ld-linux-loongarch-ilp32s.so.1


这边改回从 1 开始编号 ld.so 版本，我个人是 OK 的（我觉得从 0 从 1 开始都有它的道理，从 0 开始是代表着 LoongArch 特殊的旧世界遗产，1 代表纯社区版本、社区共同制定规范的新世界开端），但前面 #24 多数意见都更喜欢从 1 开始，那么我更没问题了

xen0n · 2021-11-04T11:04:47Z

docs/LoongArch-toolchain-conventions-CN.adoc

@@ -277,7 +278,7 @@ v1.00 定义的指令集架构
 |`<fabi_suffix>` 字符串    |含义
 |`f64`                     |基础 ABI 使用 64 位浮点寄存器传参 (`lp64d` `ilp32d`)
 |`f32`                     |基础 ABI 使用 32 位浮点寄存器传参 (`lp64f` `ilp32f`)
-|`sfp`                     |基础 ABI 不使用浮点寄存器传参 (`lp64s` `ilp32s`)
+|`sf`                      |基础 ABI 不使用浮点寄存器传参 (`lp64s` `ilp32s`)


xen0n · 2021-11-04T11:05:25Z

docs/LoongArch-toolchain-conventions-CN.adoc

+|`-march` 指定的目标 CPU 名称，若未指定则为默认值

 |`_LOONGARCH_TUNE`
 |`"loongarch64"` `"la464"`
-|相当于 `-mtune` 指定的目标 CPU 名称
+|`-mtune` 指定的目标 CPU 名称，若未指定则为默认值


英文版写的是“（编译器）构建时指定的默认值”，这边改一下

xen0n · 2021-11-04T11:14:36Z

另外还有一个值得注意的情况：目前的文本规定了 __loongarch__ 等符号取空值（即等价于 #define __loongarch__），而目前的 gcc LA 开发分支上，行为是 #define __loongarch__ 1。

对于 #ifdef FOO 的用法，两种做法的效果等价；而对于 #if FOO 的用法，FOO 取空值会造成编译错误。考虑用户的编码习惯参差不齐，以及可能存在的预处理器 tricks（我目前想不到场景），可能保持现有做法给一个 1 会比较新手友好。

xen0n · 2021-11-04T11:15:52Z

cc @chenhuacai @sunhaiyong1978 @yetist @xry111 来新串讨论

ChenghuaXu · 2021-11-04T11:37:42Z

#24 中剩余的几个问题：

v0/v1/fv0/fv1 的具体处理细节；

裸的 char 有无符号的提示文字；

带版本的 -march 取值；

-march -mtune 取值上未来添加变换的可能性，处理方式；

_LOONGARCH_XXX 命名风格不一致的符号的处理；

ABI flag 表格的排序。
要不每一项单独开pr或issues讨论？这样达成一致的尽快可以合入，另外讨论也比较聚焦。

chenhuacai · 2021-11-04T12:01:41Z

cc @chenhuacai @sunhaiyong1978 @yetist @xry111 来新串讨论

我依然认为ABI的名字并不必须要等同数据类型的名字，甚至不要任何字幕前缀，直接用32s/32f/32d/64s/64f/64d我都觉得可以，甚至更好。

scylaac · 2021-11-04T13:27:01Z

要不每一项单独开pr或issues讨论？这样达成一致的尽快可以合入，另外讨论也比较聚焦。

首先感谢大家积极贡献建议。整理文档是一个不断迭代的过程，很难一次性考虑到全部需求，出现未规范、不明确的内容在所难免，不过也可以逐步修正。

目前大部分对编译器具体行为的规范都已形成了一定的共识。所以关于增强文档规范性（比如未来扩展，提示文字）的其他内容，另外提出PR讨论感觉比较好。

xry111 · 2021-11-04T15:01:57Z

cc @chenhuacai @sunhaiyong1978 @yetist @xry111 来新串讨论

我依然认为ABI的名字并不必须要等同数据类型的名字，甚至不要任何字幕前缀，直接用32s/32f/32d/64s/64f/64d我都觉得可以，甚至更好。

这里实质是我们到底应不应该认为 LLP64 (如果有) 和 LP64 的目标文件 ABI 兼容 (可以链接)。

如果认为它们兼容 (比如将 LLP64 和 LP64 代码写成在接口上都用 int64_t 这样的东西而不用 long/long long，理论上链接它们毫无问题)，那么就应该把 LP 删掉。

否则，就不能删，而是应该在需要 LLP64 的时候引入新的 ABI 类型。

如果说“我们永远不会用 LLP64 这种鬼东西”，那就删不删都行，纯粹从美学角度考虑即可。

xen0n · 2021-11-05T06:30:40Z

docs/LoongArch-toolchain-conventions-CN.adoc

+对于编译器实现来说，此时推荐的行为是报错退出，但出于易用性的考量，
+也可以在默认配置允许的范围内谨慎地选择一种当前可用指令集能够实现的
+"降级" ABI。例如，对于默认 ABI 为 `lp64d` / `base` 的编译器，
+若编译选项为 `-mfpu=none` ，则可以自动调整 ABI 到 `lp64s` / `base` 。

-.目标架构和默认 ABI 类型对应关系
+当编译选项不能唯一确定目标架构时，编译器应当首先检查默认值是否能满足
+ABI 配置的需要。若不能，则应根据下表，在默认可用指令集基础上增加选用
+缺失的模块，但不违反已给出编译选项对目标架构的明确约束。


当编译器进行猜测的时候，建议规定应当报出警告（warning）以提示用户注意自己的行为。

chenhuacai · 2021-11-05T08:28:12Z

cc @chenhuacai @sunhaiyong1978 @yetist @xry111 来新串讨论

我依然认为ABI的名字并不必须要等同数据类型的名字，甚至不要任何字幕前缀，直接用32s/32f/32d/64s/64f/64d我都觉得可以，甚至更好。

这里实质是我们到底应不应该认为 LLP64 (如果有) 和 LP64 的目标文件 ABI 兼容 (可以链接)。

如果认为它们兼容 (比如将 LLP64 和 LP64 代码写成在接口上都用 int64_t 这样的东西而不用 long/long long，理论上链接它们毫无问题)，那么就应该把 LP 删掉。

否则，就不能删，而是应该在需要 LLP64 的时候引入新的 ABI 类型。

如果说“我们永远不会用 LLP64 这种鬼东西”，那就删不删都行，纯粹从美学角度考虑即可。

我就是认为我们永远不会用LLP64这种鬼东西，如果哪天LLP64跟LP64同时存在，那一定是一个灾难，随时火葬场的那种。

xen0n · 2021-11-05T09:26:56Z

cc @chenhuacai @sunhaiyong1978 @yetist @xry111 来新串讨论

我依然认为ABI的名字并不必须要等同数据类型的名字，甚至不要任何字幕前缀，直接用32s/32f/32d/64s/64f/64d我都觉得可以，甚至更好。

这里实质是我们到底应不应该认为 LLP64 (如果有) 和 LP64 的目标文件 ABI 兼容 (可以链接)。
如果认为它们兼容 (比如将 LLP64 和 LP64 代码写成在接口上都用 int64_t 这样的东西而不用 long/long long，理论上链接它们毫无问题)，那么就应该把 LP 删掉。
否则，就不能删，而是应该在需要 LLP64 的时候引入新的 ABI 类型。
如果说“我们永远不会用 LLP64 这种鬼东西”，那就删不删都行，纯粹从美学角度考虑即可。

我就是认为我们永远不会用LLP64这种鬼东西，如果哪天LLP64跟LP64同时存在，那一定是一个灾难，随时火葬场的那种。

我的观点始终是 方便学习，并非非要跟 LLP64 这种东西并列才能说明 LP64 这样写法的必要性；广泛的社区里接受，学校里教，别的新兴架构用，研发人员喜闻乐见，那就使用。没有必要非得搞一套跟别人都不一样的，不超过 6 个的字母数字组合还能上税不成？

xry111 · 2021-11-05T10:45:24Z

cc @chenhuacai @sunhaiyong1978 @yetist @xry111 来新串讨论

我依然认为ABI的名字并不必须要等同数据类型的名字，甚至不要任何字幕前缀，直接用32s/32f/32d/64s/64f/64d我都觉得可以，甚至更好。

这里实质是我们到底应不应该认为 LLP64 (如果有) 和 LP64 的目标文件 ABI 兼容 (可以链接)。
如果认为它们兼容 (比如将 LLP64 和 LP64 代码写成在接口上都用 int64_t 这样的东西而不用 long/long long，理论上链接它们毫无问题)，那么就应该把 LP 删掉。
否则，就不能删，而是应该在需要 LLP64 的时候引入新的 ABI 类型。
如果说“我们永远不会用 LLP64 这种鬼东西”，那就删不删都行，纯粹从美学角度考虑即可。

我就是认为我们永远不会用LLP64这种鬼东西，如果哪天LLP64跟LP64同时存在，那一定是一个灾难，随时火葬场的那种。

我的观点始终是 方便学习，并非非要跟 LLP64 这种东西并列才能说明 LP64 这样写法的必要性；广泛的社区里接受，学校里教，别的新兴架构用，研发人员喜闻乐见，那就使用。没有必要非得搞一套跟别人都不一样的，不超过 6 个的字母数字组合还能上税不成？

如果没有必要改就接着用 LP64/ILP32 吧，反正就是个名字。

不过如果我自己啥都不参考的话会用 I64F64 这样的 (其他人看来可能觉得我有病) 的名字。

chenhuacai · 2021-11-07T09:32:54Z

cc @chenhuacai @sunhaiyong1978 @yetist @xry111 来新串讨论

我依然认为ABI的名字并不必须要等同数据类型的名字，甚至不要任何字幕前缀，直接用32s/32f/32d/64s/64f/64d我都觉得可以，甚至更好。

这里实质是我们到底应不应该认为 LLP64 (如果有) 和 LP64 的目标文件 ABI 兼容 (可以链接)。
如果认为它们兼容 (比如将 LLP64 和 LP64 代码写成在接口上都用 int64_t 这样的东西而不用 long/long long，理论上链接它们毫无问题)，那么就应该把 LP 删掉。
否则，就不能删，而是应该在需要 LLP64 的时候引入新的 ABI 类型。
如果说“我们永远不会用 LLP64 这种鬼东西”，那就删不删都行，纯粹从美学角度考虑即可。

我就是认为我们永远不会用LLP64这种鬼东西，如果哪天LLP64跟LP64同时存在，那一定是一个灾难，随时火葬场的那种。

我的观点始终是 方便学习，并非非要跟 LLP64 这种东西并列才能说明 LP64 这样写法的必要性；广泛的社区里接受，学校里教，别的新兴架构用，研发人员喜闻乐见，那就使用。没有必要非得搞一套跟别人都不一样的，不超过 6 个的字母数字组合还能上税不成？

如果没有必要改就接着用 LP64/ILP32 吧，反正就是个名字。

不过如果我自己啥都不参考的话会用 I64F64 这样的 (其他人看来可能觉得我有病) 的名字。

我觉得这样取名非常好。

ChenghuaXu · 2021-11-09T07:48:59Z

我个人强烈建议使用lp64d/f/s和ilp32d/f/s。两点：一、这样确实沟通起来比较明确，我之前在发glibc patch时，说了32位abi不能工作，大佬明确指出别简单说32位，指代不明。二、时间上较新的架构，aarch64和risc-v都是用这么用的。

ChenghuaXu · 2021-11-09T09:12:00Z

@scylaac v0v1要不要删掉的另外一个pr讨论了，宏定义也是。把细节按上面的讨论调整一下，abi名称还是按lp64和ilp32加浮点后缀走，大家要没意见，这个可以尽快合入了。

xen0n · 2021-11-09T10:59:44Z

我个人强烈建议使用lp64d/f/s和ilp32d/f/s。两点：一、这样确实沟通起来比较明确，我之前在发glibc patch时，说了32位abi不能工作，大佬明确指出别简单说32位，指代不明。二、时间上较新的架构，aarch64和risc-v都是用这么用的。

For the record: 其他架构（可能主要是 RV）的软浮点 ABI 名字里不带 S 字样，我前面也表达过 F/D/S 共存时“单精度”到底取 F 还是 S 的疑虑；经过考虑，我认为这不是个问题，因为 RV ABI 命名采用的 F/D/(none) 区分可以认为已经深入人心，且此处的叙述不会让人产生 SP/DP 的联想。相反，我们把表示软浮点的 S 明确写出，反而表意更清晰了。我同意使用 LP64{F,D,S} ILP32{F,D,S} 的 ABI 命名。

scylaac · 2021-11-10T02:52:37Z

@yetist @FreeFlyingSheep @chenhuacai @xry111 请求 review :)

psABI 文档中各 ABI 的排列顺序暂时先不动了，我认为不一定要按照 e_flags 取值排序。如果改的话，下面的 ld.so 路径表顺序也需要同步。

xen0n · 2021-11-10T03:09:18Z

psABI 文档中各 ABI 的排列顺序暂时先不动了，我认为不一定要按照 e_flags 取值排序。

不认同，表格应该方便查阅。那张表格的预期使用者，基本可以认为都是带着一个数字过来查含义的，不按数值排序的话会给用户造成困扰。另外不理解为何 D/F/S 顺序就好，S/F/D 顺序就不好。

如果改的话，下面的 ld.so 路径表顺序也需要同步。

我觉得改不改都行，这个是次要问题。

yetist · 2021-11-10T04:46:20Z

gcc 预定义宏和 tuple 名字确定好了吗？ systemd 上游补丁 systemd/systemd#21288 (comment) 需要根据这些信息把 "loongarch64-linux-gnu" 拆分成3个(s、f、d)。

scylaac · 2021-11-10T05:10:11Z

gcc 预定义宏和 tuple 名字确定好了吗？ systemd 上游补丁 systemd/systemd#21288 (comment) 需要根据这些信息把 "loongarch64-linux-gnu" 拆分成3个(s、f、d)。

规范目标三元组的名字都确定了，预定义宏目前还有争议，见 #28 。

scylaac · 2021-11-16T09:20:51Z

ABI 表格排列顺序已修改。

xen0n

🆗

yetist

LGTM

ChenghuaXu approved these changes Nov 4, 2021

View reviewed changes

xen0n reviewed Nov 4, 2021

View reviewed changes

xen0n mentioned this pull request Nov 4, 2021

Update LoongArch psABI and toolchain conventions. #24

Merged

scylaac force-pushed the tc-psabi-fix branch from f8952d6 to 8596a61 Compare November 4, 2021 09:58

xen0n reviewed Nov 4, 2021

View reviewed changes

scylaac force-pushed the tc-psabi-fix branch from 8596a61 to 898ad1c Compare November 4, 2021 13:46

xen0n mentioned this pull request Nov 5, 2021

Deprecate $v* and $fv* aliases in the ELF psABI docs. #27

Merged

xen0n reviewed Nov 5, 2021

View reviewed changes

This was referenced Nov 8, 2021

Update the C/C++ preprocessor built-in macros sections #28

Merged

ELF psABI document fixes #8

Closed

Add procedure calling convention #26

Closed

scylaac force-pushed the tc-psabi-fix branch from 898ad1c to db14d9e Compare November 10, 2021 02:39

xen0n mentioned this pull request Nov 10, 2021

Add support for the LoongArch architecture. systemd/systemd#21288

Merged

xen0n mentioned this pull request Nov 10, 2021

arch: add loongarch support. loongarch64/fio#1

Open

Fix toolchain conventions and psABI document.

436f21a

scylaac force-pushed the tc-psabi-fix branch from db14d9e to 436f21a Compare November 16, 2021 09:19

xen0n approved these changes Nov 16, 2021

View reviewed changes

yetist approved these changes Nov 16, 2021

View reviewed changes

FreeFlyingSheep approved these changes Nov 16, 2021

View reviewed changes

FreeFlyingSheep merged commit 23d53fe into loongson:main Nov 16, 2021

Calring mentioned this pull request Nov 16, 2021

Add procedure calling convention. #30

Closed

xen0n mentioned this pull request Feb 9, 2023

Adjust the Multiarch Specifier #80

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix toolchain conventions and psABI document. #25

Fix toolchain conventions and psABI document. #25

scylaac commented Nov 4, 2021

ChenghuaXu left a comment

xen0n Nov 4, 2021

scylaac Nov 4, 2021

xen0n Nov 4, 2021

FreeFlyingSheep commented Nov 4, 2021

yetist commented Nov 4, 2021

xen0n left a comment

xen0n Nov 4, 2021

xen0n Nov 4, 2021

xen0n Nov 4, 2021

xen0n commented Nov 4, 2021

xen0n commented Nov 4, 2021

ChenghuaXu commented Nov 4, 2021

chenhuacai commented Nov 4, 2021

scylaac commented Nov 4, 2021 •

edited

Loading

xry111 commented Nov 4, 2021 •

edited

Loading

xen0n Nov 5, 2021

chenhuacai commented Nov 5, 2021

xen0n commented Nov 5, 2021

xry111 commented Nov 5, 2021

chenhuacai commented Nov 7, 2021

ChenghuaXu commented Nov 9, 2021

ChenghuaXu commented Nov 9, 2021

xen0n commented Nov 9, 2021

scylaac commented Nov 10, 2021

xen0n commented Nov 10, 2021

yetist commented Nov 10, 2021

scylaac commented Nov 10, 2021 •

edited

Loading

scylaac commented Nov 16, 2021

xen0n left a comment

yetist left a comment

Fix toolchain conventions and psABI document. #25

Fix toolchain conventions and psABI document. #25

Conversation

scylaac commented Nov 4, 2021

ChenghuaXu left a comment

Choose a reason for hiding this comment

xen0n Nov 4, 2021

Choose a reason for hiding this comment

scylaac Nov 4, 2021

Choose a reason for hiding this comment

xen0n Nov 4, 2021

Choose a reason for hiding this comment

FreeFlyingSheep commented Nov 4, 2021

yetist commented Nov 4, 2021

xen0n left a comment

Choose a reason for hiding this comment

xen0n Nov 4, 2021

Choose a reason for hiding this comment

xen0n Nov 4, 2021

Choose a reason for hiding this comment

xen0n Nov 4, 2021

Choose a reason for hiding this comment

xen0n commented Nov 4, 2021

xen0n commented Nov 4, 2021

ChenghuaXu commented Nov 4, 2021

chenhuacai commented Nov 4, 2021

scylaac commented Nov 4, 2021 • edited Loading

xry111 commented Nov 4, 2021 • edited Loading

xen0n Nov 5, 2021

Choose a reason for hiding this comment

chenhuacai commented Nov 5, 2021

xen0n commented Nov 5, 2021

xry111 commented Nov 5, 2021

chenhuacai commented Nov 7, 2021

ChenghuaXu commented Nov 9, 2021

ChenghuaXu commented Nov 9, 2021

xen0n commented Nov 9, 2021

scylaac commented Nov 10, 2021

xen0n commented Nov 10, 2021

yetist commented Nov 10, 2021

scylaac commented Nov 10, 2021 • edited Loading

scylaac commented Nov 16, 2021

xen0n left a comment

Choose a reason for hiding this comment

yetist left a comment

Choose a reason for hiding this comment

scylaac commented Nov 4, 2021 •

edited

Loading

xry111 commented Nov 4, 2021 •

edited

Loading

scylaac commented Nov 10, 2021 •

edited

Loading