工具链Tuples讨论 about loongarch-documentation

[xen0n]

确认个事情：上面我们讨论的都是 Multiarch tuples，但仍然需要指定 GNU tuples 的行为。

尤其是 loongarch64-unknown-linux-gnu 这个不带 ABI 后缀的写法，可能已经有上游项目接受了之前做完的适配工作了，需要兼容。需要明确：应当将其当作 loongarch64-unknown-linux-gnuf64 处理，还是报错。

我倾向于当作 LP64D ABI 处理。

虽然 ILP32 ABI 从未得到完整支持，但为了降低学习成本，我倾向于将 loongarch32-unknown-linux-gnu 也当作 loongarch32-unknown-linux-gnuf64 即 ILP32D，免得需要记住“32 位默认是软浮点”之类的奇奇怪怪东西。

[xen0n]

按照 Debian Wiki 上现有 multiarch tuples 遵循的规律，对于 ARCH-OS-ENV 三元组，ARCH 部分均表现 endianness 和 word size，ABI 都体现在 ENV 部分。因此我倾向于 loongarchNN-linux-gnuABISUFFIX 的写法。

[chenhuacai]

我同意方案1。

[ChenghuaXu]

笔误：
目前有两个方案：
1、loongarch*-linux-gnu。
2、loongarch64-linux-gnu*。

[yetist]

另一个参考源，gnu config 的测试用例数据，说明的是现状：

https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob;f=testsuite/config-guess.data;h=bc26e03eb4ea77e6a06acb9b3869ef27157c202d;hb=HEAD

https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob;f=testsuite/config-sub.data;h=d58521bebc5b39e06ff4722c8601d438803a44db;hb=HEAD

[sunhaiyong1978]

我提一个新建议啊，但愿不会把事情搞复杂了。
我建议如果不同的tuples编译的库不兼容可以考虑第一部分不相同，如果是兼容的就是最后部分不同。
就是组合两者：loongarch*-unknown-linux-gnu*

[yetist]

搜遍全网，看起来就 debian 在积极推广多库、多架构这东西，还整了个 spec，其他发行版（包括gnu），不在乎这个事。
现在的问题是，debian 推的这东西能不能推广开来，弄到上游让其他发行版也采用，如果行，那按 debian 的设计来可以一次到位，如果不行，对别的发行版和现有工具会不会带来麻烦。

[xen0n]

搜遍全网，看起来就 debian 在积极推广多库、多架构这东西，还整了个 spec，其他发行版（包括gnu），不在乎这个事。 现在的问题是，debian 推的这东西能不能推广开来，弄到上游让其他发行版也采用，如果行，那按 debian 的设计来可以一次到位，如果不行，对别的发行版和现有工具会不会带来麻烦。

目前 multiarch 可以认为是 Debian-specific 的东西，因此我们从这里只是获取启发，以改进我们自己对 target tuples 的定义。当然，Debian multiarch tuples 基本是延续了 GNU tuples 的一贯风格，我前面提到的 ARCH-OS-ENV 哪一部分表达哪些含义这一点也是和绝大多数 GNU tuples 现有做法保持一致的，因此我觉得其实不矛盾。

[scylaac]

ABI 类型（基础 ABI / ABI 扩展特性）	操作系统类型	规范三元组（Multiarch 标识符）
lp64d / base	GNU/Linux	loongarch64-linux-gnuf64
lp64f / base	GNU/Linux	loongarch64-linux-gnuf32
lp64s / base	GNU/Linux	loongarch64-linux-gnusf
ilp32d / base	GNU/Linux	loongarch32-linux-gnuf64
ilp32f / base	GNU/Linux	loongarch32-linux-gnuf32
ilp32s / base	GNU/Linux	loongarch32-linux-gnusf

大家好，目前我们暂定用文档里面这个方案提交 GCC 上游，如果合并前有问题再讨论修改。

[chenhuacai]

确认个事情：上面我们讨论的都是 Multiarch tuples，但仍然需要指定 GNU tuples 的行为。

尤其是 loongarch64-unknown-linux-gnu 这个不带 ABI 后缀的写法，可能已经有上游项目接受了之前做完的适配工作了，需要兼容。需要明确：应当将其当作 loongarch64-unknown-linux-gnuf64 处理，还是报错。

我倾向于当作 LP64D ABI 处理。

虽然 ILP32 ABI 从未得到完整支持，但为了降低学习成本，我倾向于将 loongarch32-unknown-linux-gnu 也当作 loongarch32-unknown-linux-gnuf64 即 ILP32D，免得需要记住“32 位默认是软浮点”之类的奇奇怪怪东西。

unknown能改掉吗？看着像是个临时的什么东西似的。

[xen0n]

确认个事情：上面我们讨论的都是 Multiarch tuples，但仍然需要指定 GNU tuples 的行为。
尤其是 loongarch64-unknown-linux-gnu 这个不带 ABI 后缀的写法，可能已经有上游项目接受了之前做完的适配工作了，需要兼容。需要明确：应当将其当作 loongarch64-unknown-linux-gnuf64 处理，还是报错。
我倾向于当作 LP64D ABI 处理。
虽然 ILP32 ABI 从未得到完整支持，但为了降低学习成本，我倾向于将 loongarch32-unknown-linux-gnu 也当作 loongarch32-unknown-linux-gnuf64 即 ILP32D，免得需要记住“32 位默认是软浮点”之类的奇奇怪怪东西。

unknown能改掉吗？看着像是个临时的什么东西似的。

不改，那个字段是 ARCH-VENDOR-OS-ENV 的 VENDOR 部分，按照规范，可以随便指定的。目前除了 x86 这个地方一般写 pc，别的架构基本都写 unknown。考虑到未来会有其他公司提供龙芯架构的产品，这里写 loongson 也不合适，那么最稳妥的做法就是保持 unknown 不变。

EDIT: 我描述的是 Gentoo 的做法，Debian 似乎是不写 VENDOR 部分的，查了 aarch64 和 riscv64 的都没写，x86_64 只有 pkg-config 工具写了 unknown。我仍然不建议在这个阶段就给 VENDOR 字段赋予意义。

[yetist]

大家好，目前我们暂定用文档里面这个方案提交 GCC 上游，如果合并前有问题再讨论修改。

loongarch64-linux-gnuf32 和 loongarch32-linux-gnuf64 怎么感觉哪里不对？这种有前64后32，前32后64真的很有必要吗？

[ChenghuaXu]

大家好，目前我们暂定用文档里面这个方案提交 GCC 上游，如果合并前有问题再讨论修改。

loongarch64-linux-gnuf32 和 loongarch32-linux-gnuf64 怎么感觉哪里不对？这种有前64后32，前32后64真的很有必要吗？
对应64上只有单精度浮点情况和32上使用64位浮点，虽然目前没有这样的实现，不排除以后1系列或2系列实现，3系列应不会。

[MaskRay]

powerpc64-vendor-linux-gnu因爲過長，有時候被簡寫爲ppc64-vendor-linux-gnu，反而增加了工具鏈target triple維護負擔。

Debian風格省略vendor的寫法其實只有Debian/Ubuntu等derivatives在用。上游GCC保留vendor的。

[xen0n]

EDIT: 我描述的是 Gentoo 的做法，Debian 似乎是不写 VENDOR 部分的，查了 aarch64 和 riscv64 的都没写，x86_64 只有 pkg-config 工具写了 unknown。我仍然不建议在这个阶段就给 VENDOR 字段赋予意义。

Debian風格省略vendor的寫法其實只有Debian/Ubuntu等derivatives在用。上游GCC保留vendor的。

补充说明：我前面指的“不建议给 VENDOR 字段赋予意义”，意思是不建议规定 unknown 以外的取值及其含义，而非不写该字段。

[sunhaiyong1978]

unknow这个不用纠结，大多发行版都会去改的。

[xen0n]

unknow这个不用纠结，大多发行版都会去改的。

我没在纠结，只是回答 @chenhuacai 的疑惑。希望上面的说明可以解决掉这个疑问。

[yetist]

对应64上只有单精度浮点情况和32上使用64位浮点，虽然目前没有这样的实现，不排除以后1系列或2系列实现，3系列应不会。

希望就一种最好，32位一种，64位一种，支持的越多，越碎片化，对生态不利。

[ChenghuaXu]

对应64上只有单精度浮点情况和32上使用64位浮点，虽然目前没有这样的实现，不排除以后1系列或2系列实现，3系列应不会。

希望就一种最好，32位一种，64位一种，支持的越多，越碎片化，对生态不利。
这个不叫碎片化，本来就是不同的东西，目前规划好，可以避免后续的混乱。

[xen0n]

对应64上只有单精度浮点情况和32上使用64位浮点，虽然目前没有这样的实现，不排除以后1系列或2系列实现，3系列应不会。

希望就一种最好，32位一种，64位一种，支持的越多，越碎片化，对生态不利。

我的预期是非嵌入式场景永远不要让人看到 LP64D 之外的东西，剩余的 99.9% 嵌入式场景下也尽量不要让人看到 LP64D ILP32D ILP32S 之外的其他 ABI，但规范制定的时候显然是要把所有可能的组合都列出来的。

[yetist]

对应64上只有单精度浮点情况和32上使用64位浮点，虽然目前没有这样的实现，不排除以后1系列或2系列实现，3系列应不会。

希望就一种最好，32位一种，64位一种，支持的越多，越碎片化，对生态不利。

我的预期是非嵌入式场景永远不要让人看到 LP64D 之外的东西，剩余的 99.9% 嵌入式场景下也尽量不要让人看到 LP64D ILP32D ILP32S 之外的其他 ABI，

就是这个意思。说的就是前32后64和前64后32这两种，他们最好不要出现。甚至 ilp32s 在未来的现实场景中可能也不会太多---嵌入式领域的一个趋势是用的硬件越来越高，大家都开始用64位arm v8处理器来做了，并且有加速趋势。

但规范制定的时候显然是要把所有可能的组合都列出来的。

这种说法有道理，但我仍然担心这2种是不是属于过度设计。

[xen0n]

对应64上只有单精度浮点情况和32上使用64位浮点，虽然目前没有这样的实现，不排除以后1系列或2系列实现，3系列应不会。

希望就一种最好，32位一种，64位一种，支持的越多，越碎片化，对生态不利。

我的预期是非嵌入式场景永远不要让人看到 LP64D 之外的东西，剩余的 99.9% 嵌入式场景下也尽量不要让人看到 LP64D ILP32D ILP32S 之外的其他 ABI，

就是这个意思。说的就是前32后64和前64后32这两种，他们最好不要出现。

同意。实在害怕的话不妨在规范里加入叙述，“极少数特殊定制场景下，可能用到……，不建议通用场景实现/支持”，以传达一些负面影响，也是尽量让用户别给自己找麻烦。

甚至 ilp32s 在未来的现实场景中可能也不会太多---嵌入式领域的一个趋势是用的硬件越来越高，大家都开始用64位arm v8处理器来做了，并且有加速趋势。

这个不一定，嵌入式的宇宙实在太宽广了。能想像一些更小的核（包括但不限于 MCU、可穿戴等等）可能有这需求。虽然龙芯自己没有这种解决方案提供，但目前 LA 如果是真心想做产业联盟而不是单纯画饼圈钱，那么也应该考虑到这些其他企业存在的可能性。

但规范制定的时候显然是要把所有可能的组合都列出来的。

这种说法有道理，但我仍然担心这2种是不是属于过度设计。

如上所说，担心的话在规范里不推荐别人实现就是了。

[chenhuacai]

对应64上只有单精度浮点情况和32上使用64位浮点，虽然目前没有这样的实现，不排除以后1系列或2系列实现，3系列应不会。

希望就一种最好，32位一种，64位一种，支持的越多，越碎片化，对生态不利。

我的预期是非嵌入式场景永远不要让人看到 LP64D 之外的东西，剩余的 99.9% 嵌入式场景下也尽量不要让人看到 LP64D ILP32D ILP32S 之外的其他 ABI，

就是这个意思。说的就是前32后64和前64后32这两种，他们最好不要出现。甚至 ilp32s 在未来的现实场景中可能也不会太多---嵌入式领域的一个趋势是用的硬件越来越高，大家都开始用64位arm v8处理器来做了，并且有加速趋势。

但规范制定的时候显然是要把所有可能的组合都列出来的。

这种说法有道理，但我仍然担心这2种是不是属于过度设计。

我觉得是过度设计，也许上游也会这么认为。

[ChenghuaXu]

代码已合入上游社区，关闭。