loongson / loongarch-documentation Goto Github PK

问题描述

Procedure Calling Convention的目录结构不正确，"ABI LP64D"这个标题的级别应当高于“Argument Registers" "C Data Types and Alignment" "Argument Passing"和"Return values"。

比如这段：

这应该只适用于"*D"或"*F"的ABI，不适用于”*S“的ABI。

再比如这段：

从内容上看，这里只描述了LP64D的情况。

再比如这段：

这里看起来应该是假设GRLEN=64, FRLEN=64。因为整段描述都没有判断FRLEN。

再比如这段：

这应该只适用于"*D"或"*F"的ABI，不适用于”*S“的ABI。

如题

有没有想过你们也提供这个？
https://github.com/trcrsired/windows-hosted-loongarch64-linux-gnu-gcc-cross-comiler

还有loongarch这个体系结构支持addcarry么？令人很不爽的关于riscv就是没有任何办法处理addcarry和subborrow.

加上herb sutter的P0709的Herbceptions需要额外的标志位表示函数是否出错，x86和arm上是用的carry位。但看loongarch似乎也没有标志位是么？有没有什么替代方案？

Consider such cases:

Case 1:

struct f
{
	double x[0];   /* This is a GNU extension.  */
	double a;
	double b;
};

Case 2:

struct f
{
        float x[0];
        float b;
};

Case 3:

struct f
{
        double x[0];
        float b;
};

Current calling convention doc is not clear on "if f::x is considered a member", "if f::x is considered a floating-point member", and "if f::x is considered one float (or double) member". Note that we are saying:

Empty structures are ignored by C compilers which support them as a non-standard extension

But it does not cover "empty" arrays.

And current GCC trunk is doing strange things (IMO). For Case 2, it passes b in FAR. But for Case 3, it passes b in GAR.

In my opinion the most "clear" solution is to ignore the empty arrays (and bitfields: https://gcc.gnu.org/PR102024) altogether with empty aggreates. But that will requires to update GCC behavior, fortunately we still have an oppertunity to do this before GCC 12 release (if we move fast). CC GCC maintainers: @ChenghuaXu @chenglulu

Another solution is to document the current GCC behavior clearly in the doc. But I don't know to write it (as I consider the current behavior "strange").

请在龙芯平台上支持D语言编译器LDC（基于LLVM的跨平台编译器且支持交叉编译）便于后续多个旧项目代码的编译与适配。

众所周知，目前准备推上游的 LoongArch 内核-用户界面 ABI 与早已出货的几种商业发行版并不兼容：

• 已有商业系统内核版本是 4.19，而从上游角度，不会有早于 5.1x 的内核存在 LoongArch 支持；
• 已有商业系统的 glibc 全部低于 2.34，libpthread.so 不是 stub，而从上游角度，LoongArch glibc 自始没有分立的 libpthread.so；
• 已有商业系统的 NSIG、struct sigcontext 等等内容与上游接受的内容不同，

由于早期 LoongArch 生态的建设没有征询社区意见，而导致了这些现状：LoongArch 生态自始就分裂为两套互不兼容的体系，来自一个世界的 userland 无法在另一个世界的内核上正常工作。

尽管我们无法回到过去解决这些问题，但好在新旧世界的不兼容性目前仍然可控，因此可以尽早设计出适配方案，以实现新世界对旧世界闭源软件的兼容。预期未来随着 LoongArch 支持逐渐合入上游，各大商业发行版迟早都会 rebase & rebuild 到新世界，因此可以暂时不考虑旧世界上执行新世界应用的场景。

目前对于动态链接的可执行文件，可以通过 ELF interpreter 路径来区分新旧世界的程序。但对于静态链接的情况，需要有别的方式来可靠确定当前进程的 flavor，以便在需要的时刻正确截获、翻译系统调用。

这里先把问题抛出来，看看社区里大家都怎么想。我自己的方案可能一两天内整理好发出来。

中文版文档呢？放出来的怎么都是英文版文档呢？
龙芯来自**，我们把中文作为第一支持语言，不过份吧？
不管是从教育，或者吸引国内开发者来说，一份中文文档，有必要的吧？功在当代，利在千秋。
不觉得就算优先提供英文文档，又会有多少外国人愿意真正支持和帮助龙芯发展。

https://gitee.com/src-openeuler/glibc/blob/openEuler-22.03-LTS-LoongArch/0001-LoongArch-Port.patch#L6467
https://gitee.com/src-openeuler/glibc/blob/openEuler-22.03-LTS-LoongArch/0001-LoongArch-Port.patch#L10676

https://github.com/bminor/glibc/blob/glibc-2.36/sysdeps/unix/sysv/linux/loongarch/configure#L4
https://github.com/bminor/glibc/blob/glibc-2.36/sysdeps/unix/sysv/linux/loongarch/shlib-versions#L1

我发现龙芯贡献给euler的和上游的值不相符 这似乎会造成新世界发行版之间二进制不兼容吧

Describe the bug:

The links on the main README page don't work.

Steps to reproduce:

Open the main github page for the project, scroll to the readme, and click on any link other than the original documentation links.

Expected behavior:

Documents should open when clicked upon.

Screenshots:

Additional context:

It looks like the links are simply missing the /doc directory reference.

Environment:

• Operating system:
• Browser/application:
• Browser/application version:

Describe the question:

C库或者一些系统调用相关的库函数在实现时需要知道向内核参数传递的寄存器约定和寄存器里面的值的销毁情况。目前ABI文档中没有这样的描述。

Describe the idea:

Additional context:

我使用codetyphon的 ctc 工具，管理维护交叉编译环境，能看到有MIPS架构，但还没有longgarch 架构。使用各种MIPS和MIPS64都不能顺利交叉编译我的应用。我的桌面应用已经能够在codetyphon中交叉编译出X86和ARM的Linux 应用程序。期待FreePascal的龙芯版支持能够早日推出。

Describe the question:

类似x86下的mov指令和ret指令在手册中未查到
Describe the idea:

在编写loongarch64汇编时，发现传送指令（类似x86的mov），无条件跳转指令（类似ret）是缺失的，经过对一个c文件，在gcc下进行汇编编译，我们认为这几个指令是可能的：
jr指令，对应ret指令，用法为
jr $r1
la.local指令，对应mov，用法为
la.local 寄存器操作数, 被传送内容(x86下通常是.data域定义的变量)
另外还看到一个la.global不知是何含义
以上三个指令，在《loongarch架构手册第一部分》内查不到，请帮忙核实一下。
Additional context:

龙芯论坛上：x264-0.152-1在Loongnix上发布 [2020-03-03]

工具链Tuples

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

希望在这里达成一致后，修改到文档中。大家按照此约定，实现操作系统和工具链。

其他架构tuples参见：
https://wiki.debian.org/Multiarch/Tuples

EDIT: 修正一下笔误。

https://github.com/loongson/LoongArch-Documentation/blame/main/docs/LoongArch-Vol1-EN/basic-integer-instructions/overview-of-basic-integer-instructions.adoc#L37

Maybe it is LL.w?

Describe the bug:
LoongArch-Vol1-v1.00
page 81(en) 60(cn)

CULT 0xE Less than or incomparable UN LT compareQuietLessUnordered
CLE 0x6 Less than or equal to LT EQ compareQuietLessEqual
CULE 0xE Less than or equal to or incomparable UN LT EQ compareQuietNotGreater

CULT and CULE both have 0xE.

Steps to reproduce:

CULT should be 0xA
https://github.com/loongson/binutils-gdb/blob/85b10f4e45603cf1c187313a8cd5ed5ac7ac9cc6/opcodes/loongarch-opc.c#L534

 $printf "0x%x\n" $((0x0c150000>>15 &0x1f))
0xa

In the documentation (both Chinese and English) those instructions are said to match the behavior of IEEE 754-2008 maxNum and minNum operations.

IEEE 754-2008 says if one operand of those operations is a signaling NaN, the execution should signal and produce a quiet NaN. For example, according to IEEE 754-2008, the result of maxNum(sNaN, 1.0) should be qNaN.

OTOH, the test on Loongson 3A5000 shows the instructions signals for sNaN, but returns another, non-NaN operand instead of a qNaN. For example, fmax.s $f0, $f0, $f1 puts 1.0f into $f0 when $f0 contains sNaN and $f1 contains 1.0f. This does not match IEEE 754-2008, but matches the behavior of LLVM minnum/maxnum intrinsics.

IMO the documentation should be updated to show the difference. I'm not sure if the descriptions for other floating-point instructions need to be updated as well.

#29 之前tuple的讨论

现实情况是 部分发行版选择了-gnu 但是-gnu似乎在文档里没有良定义

到底要把-gnu视作-gnuf64的别名 还是不要-gnu 还是其他?

问题

在修正一个重定位相关的问题的过程中，发现LA定义了 R_LARCH_ADD24和R_LARCH_SUB24类型的重定位，相比R_LARCH_{ADD,SUB}{8,16,32,64}（这些重定位的处理有另外的问题），.eh_frame/DWARF等元数据中的地址或者偏移使用24bit宽度的重定位会让数据对齐处理非常复杂，LA ABI也未定义uint24/int24这样的数据类型；

状态

R_LARCH_ADD24 / R_LARCH_SUB24 目前没有被使用；

修改意见

• 建议在工具链中去除这两个重定位类型，binutils-gdb见补丁https://sourceware.org/pipermail/binutils/2022-May/120809.html；
• 更新psABI文档；

Describe the bug:
Hi, I was interested in LoongArch so I downloaded Volume 1, then I downloaded Volume 2 and 3, but they are blank, I also tried from the GitHub Releases page, but still no luck.
Hopefully this issue is fixed
Thanks

使用最新工具链，构建 glib2 失败。失败的构建命令如下：

/usr/sbin/ld -r -b binary gio/tests/test5.gresource -o gio/tests/test_resources.o
/usr/sbin/objcopy --add-symbol _g_binary_test1_resource_data=.data:0 gio/tests/test_resources.o gio/tests/test_resources2.o
cc  -o gio/tests/resources gio/tests/test_resources2.o gio/tests/resources.p/meson-generated_.._test_resources.c.o gio/tests/resources.p/meson-generated_.._test_resources2.c.o gio/tests/resources.p/meson-generated_.._digit_test_resources.c.o gio/tests/resources.p/meson-generated_.._test_resources_binary.c.o gio/tests/resources.p/resources.c.o -flto -Wl,--as-needed -Wl,--no-undefined -pie -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -mabi=lp64d -march=loongarch64 -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -DG_DISABLE_CAST_CHECKS '-Wl,-rpath,$ORIGIN/../../glib:$ORIGIN/../../gmodule:$ORIGIN/../../gobject:$ORIGIN/..:/usr/lib64/../lib64' -Wl,-rpath-link,/archlinux/build/glib2/src/build/glib -Wl,-rpath-link,/archlinux/build/glib2/src/build/gmodule -Wl,-rpath-link,/archlinux/build/glib2/src/build/gobject -Wl,-rpath-link,/archlinux/build/glib2/src/build/gio -Wl,-rpath-link,/usr/lib64/../lib64 -Wl,--start-group glib/libglib-2.0.so.0.7000.4 gmodule/libgmodule-2.0.so.0.7000.4 gobject/libgobject-2.0.so.0.7000.4 gio/libgio-2.0.so.0.7000.4 -Wl,--end-group
/usr/sbin/ld: gio/tests/test_resources2.o: can't link different ABI object.
/usr/sbin/ld: failed to merge target specific data of file gio/tests/test_resources2.o
collect2: 错误：ld 返回 1

出错原因：使用 ld 和 objcopy 生成的 .o 文件，其 e_flags 标志值为 0x0，无法和其他 e_flags 值为 0x3 的.o 文件一起链接。

$ readelf -h gio/tests/test_resources.o gio/tests/test_resources2.o gio/tests/resources.p/meson-generated_.._test_resources.c.o|grep 标志
  标志：             0x0                        
  标志：             0x0                            
  标志：             0x3, LP64, DOUBLE-FLOAT   

相关 规范 中 0x0 为保留值，0x3 表示 lp64d，需手工修改 gio/tests/test_resources.o、gio/tests/test_resources2.o 文件，将 0x30 处的 0x00 修改为 0x03 即可链接成功。

有什么办法可以自动构建成功？

Describe the question:
Hi, is there and open source implementation rather than loongson's own CPU?
Thanks in Advance.

Describe the bug:

Expected behavior:

Additional context:

Now,the page of https://github.com/loongson/LoongArch-Documentation/blob/main/docs/LoongArch-ELF-ABI-EN.adoc
for the ABI is too brief.
Especially the details for how the structs passed.

单精度浮点/软件浮点和正常的 LP64 代码是 ABI 不兼容的 (无法用 fa0-fa7 传参)，当前在 GCC 里面加了个特判，但是这并不是正确的做法：loongson/gcc#31 (comment)

• break和syscall指令有一个15-bit的code域，cacop指令有一个5-bit的code域，是否应该改掉其中一个的名字？
• idle指令有一个15-bit的level，lddir有一个8-bit的level，也是一样的问题。

另外卷一的网页加载较慢，经常出现页面样式不对的情况，过一段时间才会正常。
建议对卷二等未完成内容的链接显示效果做下区分，比如灰掉。不然首页看起来正常，点进去却没有相关内容，比较扫兴。

背景

在目前的移植适配实践中，对绝大部分涉及手写汇编的软件，都需要根据 GRLen、FRLen 不同，选择不同的基本操作助记符。不像 RISC-V，LoongArch 所有指令的操作宽度都是固定的（由后缀表示），这要求我们必须反复根据 is64Bit 之类的条件选择不同的指令编码。例如：

// LLVM D136074

BuildMI(MBB, MBBI, DL,
        TII->get(STI.is64Bit() ? LoongArch::SRLI_D : LoongArch::SRLI_W),
        VR)
    .addReg(SPReg)
    .addImm(ShiftAmount)
    .setMIFlag(MachineInstr::FrameSetup);
BuildMI(MBB, MBBI, DL,
        TII->get(STI.is64Bit() ? LoongArch::SLLI_D : LoongArch::SLLI_W),
        SPReg)
    .addReg(VR)
    .addImm(ShiftAmount)
    .setMIFlag(MachineInstr::FrameSetup);

// libffi

#if __SIZEOF_POINTER__ == 8
# define PTRS 8
# define LARG ld.d
# define SARG st.d
#else
# define PTRS 4
# define LARG ld.w
# define SARG st.w
#endif

// glibc
// REG_L & ADDI & BSTRINS 是这个 issue 所示问题的受害者

        LA              a0, t0, main
        REG_L           a1, sp, 0  // actually ld.d
        ADDI            a2, sp, SZREG  // actually addi.d

        /* Adjust $sp for 16-aligned */
        BSTRINS         sp, zero, 3, 0  // actually bstrins.d

// linux
// 情况与 glibc 类似

copy_word:
        /* copy page word by word */
        REG_L           s4, s1, 0
        REG_S           s4, s3, 0
        PTR_ADDI        s3, s3, SZREG
        PTR_ADDI        s1, s1, SZREG
        LONG_ADDI       s5, s5, -1
        beqz            s5, process_entry
        b               copy_word
        b               process_entry

类似的糟心事在每个项目都要重复发生一遍。

多数时候，LoongArch 汇编相关的开发工作都仅涉及手写汇编文本，而非直接生成、操作机器码。（上文的例子中，只有 LLVM 的使用姿势不被覆盖。）

如果在汇编语法层面可以提供语法糖，根据当前 -march 配置自动选择相应指令的相应宽度的形式，可能对下游汇编开发者是一种生产力的解放。

提议

• 新增 *.n、*.nu 操作符宽度后缀，用来表示与当前汇编器所 target 的 march 的 GRLen 相同的宽度。
• 所有语义上适合以原生宽度对待的、单操作符宽度后缀的指令，都应支持 .n[u] 后缀，作为相应 .w[u] 或 .d[u] 具体指令的别名。例如 ld.n、mulh.nu、slli.n。
• 语义上已经非常局限于某个领域/场景，因而不适合以原生宽度对待的指令；以及带多个操作符宽度后缀的指令，不增加相应 .n[u] 后缀的支持。例如 mulw.d.w、crc.w.w.w 等等。

讨论

• Bikeshedding（不要后缀，跟其他只操作原生宽度的指令如 xor 一样？取别的后缀？）

Describe the bug:

File: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
Section 2.2.1.4
Pseudocode for the LU52I.D instruction: it says that LU52I.D does not depend on rj:
GR[rd] = {si12, GR[rd][51:0]}

Expected behavior:

The chinese version contains the correct version: GR[rd] = {si12, GR[rj][51:0]} (notice the second rd that changed into rj).

Additional context:

All other places that I checked does not contain the issue.

Per @xen0n on #3 (comment)

Plus it seems there's a stack machine implemented with relocation records. I think this is bad for these reasons:

Fragility could ensue due to tools not respecting relative order of relocation records on the same address;
It's superficial, conveying actions and not motivations, which is generally bad smell in software engineering;
Not much complexity is shed by the introduction of intended flexibility here, so it wasn't exactly profitable either;
No prior cases wheresoever found in public code, so it's not sure if the scheme is to be appreciated universally.
I suggest removing these if possible; at the very least, continue to support this model if you MUST support the already existing early LA world with the upstreamed toolchains, but stop generating these in the future; define distinct relocation types for all the macros utilizing computation in their expansions, just like any other architecture.

As a replacement, some new relocation types with fixed bit extraction and shift can be used.

• The stack machine requires considerable complexity in the assembler. Assemblers use sym_a-sym-b+const to represent a value. It is difficult to represent shifts on a symbolic operand.
• The stack operating relocations waste space in relocatable object files.
• The stack machine is not clear what parallel relocation resolving should do.
• Various assembly producers need to deal with the complexity of a plethora of stack operating relocations.

目前movcf2gr指令的描述大致如下：

MOVCF2GR writes the value of the condition flag register cj into the lowest bit of the general register rd.
MOVCF2GR:
    GR[rd][0] = CFR[cj]

描述中只强调了会修改最低比特位，未说明其他位如何。
建议明确说明会将rd其他位清零，以减少歧义。

Describe the bug:
LoongArch-Vol1-v1.00-CN

Steps to reproduce:
PCADDU12I add 12bits zeros;
PCADDU18I add 18bits zeros;

起因

给 systemd 增加三元组的 补丁，在不经意间写了以下代码：

#if defined(__loongarch__)
#  if defined(__loongarch32)
...
# elif defined(__loongarch64)
...
#  else
...
#endif

3个人4次 review通过，准备向上游发起 PR前，鬼使神差地查了一下 gcc 源码，发现并没有定义 __loongarch32 这个宏。

讨论

由于存在 __loongarch64 这个宏，想当然的认为也存在 __loongarch32 宏，导致代码出错，并通过了代码评审。

类似的，一些外部客户发现存在 __loongarch__这个宏，往往会使用 __loongarch64__ 这个错误写法，对称美也好，直觉也好，总之是错了。

大部分开发者在写代码时，并不能完全做到时刻都去查代码、文档，大部分时候会凭借直觉和常识来写出貌似正确的代码，所以想在此讨论一下，是否有必要增加类似 __loongarch32、__loongarch64__ 这样的宏定义。