[PATCH v1 0/5] Add support for LoongArch32

[mengqinggang]

在 2025/12/3 01:00, Adhemerval Zanella Netto 写道:
>
> On 02/12/25 11:14, Xi Ruoyao wrote:
>> On Tue, 2025-12-02 at 20:57 +0800, mengqinggang wrote:
>>> These patches are based on Jiajie Chen's previous work[1].
>>> The binutils and gcc patches is here[2] [3].
>>> The binutils and gcc source code can also be find at here[4] [5].
>>> A Chinese LA32R instruction set manual is here[6].
>>> There is currently no separate LA32 instruction set manual.
>>> The LA64 instruction set manual[7] specifies the instructions
>>> available in LA32.
>> Generally Glibc does not take a Linux port until Linus' kernel tree
>> supports the machine.  Maybe LA32 isn't a completely new port, but the
>> spirit should be the same: if the ABI between kernel and userspace isn't
>> defined yet, Glibc developers are not in a position to define it.
> If the kABI is not already in the Linus tree I think it should be marked
> as RFC.
>
> And it is not clear to me how the kABI is handled, it seems to
> use the same arch-syscall.h as lp64, with the difference of mmap2 instead


arch-syscall.h copied form riscv/rv32/arch-syscall.h with some 
modifications.
I will regenerate arch-syscall.h by update-syscall-lists.py.


> of mmap. But with any other syscall as-is. Does it mean that ilp32
> uses the same kABI as lp64, with off_t, time_t, etc as 64-bit (as
> x32)?


ilp32 and lp64 have different kABI. It not a run ilp32 on LA64 ISA.


>
> At least for x32, it uses a masked syscall mechanism to handle some
> corner cases; it is not clear if or how loongarch32 requires it.  But
> it is not also clear if you intend to allow multilib support (as x86)
> or if this is handle as new abi (as for aarch64 and arm32).
>
>> And I think the epoch symbol version of LA32 should be GLIBC_2.43
>> instead of GLIBC_2.36.
>>
>> And, as a new 32-bit port (or sub-port) IMO we should start to force the
>> use of 64-bit time_t on the first day we add it, instead of repeating
>> the nasty and still ongoing time_t transition for the existing 32-bit
>> ports in the (not so far) future.
>>