LoongArch-Documentation
LoongArch-Documentation copied to clipboard
The documentation for LoongArch.
**Describe the question:** C库或者一些系统调用相关的库函数在实现时需要知道向内核参数传递的寄存器约定和寄存器里面的值的销毁情况。目前ABI文档中没有这样的描述。 **Describe the idea:** **Additional context:**
### 问题 在修正一个重定位相关的问题的过程中,发现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](https://sourceware.org/pipermail/binutils/2022-May/120809.html); - 更新psABI文档;
**问题描述** 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。
Per @xen0n on https://github.com/loongson/LoongArch-Documentation/pull/3#issuecomment-894672071 > Plus it seems there's a stack machine implemented with relocation records. I think this is bad for these reasons: > > Fragility could ensue due...
众所周知,目前准备推上游的 LoongArch 内核-用户界面 ABI 与早已出货的几种商业发行版并不兼容: - 已有商业系统内核版本是 4.19,而从上游角度,不会有早于 5.1x 的内核存在 LoongArch 支持; - 已有商业系统的 glibc 全部低于 2.34,`libpthread.so` 不是 stub,而从上游角度,LoongArch glibc 自始没有分立的 `libpthread.so`; - 已有商业系统的 `NSIG`、`struct sigcontext` 等等内容与上游接受的内容不同, 由于早期 LoongArch 生态的建设没有征询社区意见,而导致了这些现状:LoongArch...
龙芯论坛上:x264-0.152-1在Loongnix上发布 [2020-03-03]
In the BFD code (under review now), we have: #define RELOCATE_CALC_PC32_HI20(relocation, pc) \ ({ \ bfd_vma lo = (relocation) & ((bfd_vma)0xfff); \ pc = pc & (~(bfd_vma)0xfff); \ if (lo...
有没有想过你们也提供这个? 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似乎也没有标志位是么?有没有什么替代方案?