libc: add LoongArch support

[zhaoxiaoqiang007_gmail.com]

Summary

Add libc/loongarch (setjmp, makecontext, FP helpers, MD headers) and
wire loongarch into the libc, libcompiler_rt and libgcc_s build glue.

Signed-off-by: Xiaoqiang Zhao <[e-mail]>
Signed-off-by: yu shan wei <[e-mail]>

[ngie]

I would doublecheck with the original copyright holders for some of the code (@br , @kp ) about some of the questions/comments I made in the Differential.

If you could also please add SPDX-License-Identifiers to new code, that would be extremely helpful to committers.

(the contrib/netbsd-tests changes look ok BTW)

contrib/netbsd-tests/lib/libc/sys/t_getcontext.c

131

Grammar nit (Oxford comma).

lib/libc/loongarch/gen/_ctx_start.S

1–33

Should the licensing be updated here?

@emaste, @imp: I could be wrong (not a lawyer), but is carrying the DARPA/AFRL contract licensing advertisement forward necessary with the BSD-2-Clause license?

lib/libc/loongarch/gen/fpgetmask.c

5–7

Similar comment here (and elsewhere where this pattern is used) with the advertisement claim.

lib/libc/loongarch/gen/fpsetmask.c

35

"Loongarch" should probably be used here instead of "RISC-V".

[imp]

lib/libc/loongarch/gen/_ctx_start.S

1–33

This file was basically rewritten from scratch with the same copyright. The elements of this file that are the same have no copyright protection because they are required for the interface. I'd ditch the copyright on this file and use your own. I noticed that in a lot of places, but wanted to see how well this worked before taking the time to give that feedback.

That makes the DARPA and higher ed grant questions moot: they didn't fund any of this...

[zhaoxiaoqiang007_gmail.com]

lib/libc/loongarch/gen/_ctx_start.S

1–33

okay

lib/libc/loongarch/gen/fpsetmask.c

35

Yes

[shipujin.t_gmail.com]

lib/libc/loongarch/gen/_ctx_start.S

37

comment is not very clear; it is suggested to change it to:

	jirl	$ra, $s0, 0	/* call func; return here on completion */

39–40

bl has a limited branch range (~±128 MB). While ctx_done and abort are likely in range here, call36 is the safer and more conventional choice for LoongArch function calls in libc, and it matches the upstream RISC-V use of call. Suggest replacing both bls with call36.

LLVM's LoongArch support includes the call36 : llvm/lib/Target/LoongArch/Asm/LoongArchAsmParser.cpp

	call36	_C_LABEL(ctx_done)
	call36	_C_LABEL(abort)

[shipujin.t_gmail.com]

lib/libc/loongarch/gen/fabs.S

41–47

This introduces a soft-float branch in libc that will never be compiled, and the ABI assumptions of this dead-code branch conflict with the current compilation environment.

In https://reviews.freebsd.org/D59891, bsd.cpu.mk uses lp64d, which introduces a soft-float branch in libc that will never be compiled.

Suppose the else branch is taken: a double argument would be in $a0. But under the lp64d ABI, a double argument is actually in $fa0, so this code operates on the wrong register.

Suggested change to:

	fabs.d	$fa0, $fa0
	ret

[shipujin.t_gmail.com]

lib/libc/loongarch/gen/flt_rounds.c

53–55

This introduces a non-functional soft-float branch in libc; the soft-float check here should be removed.

57

Remove

[shipujin.t_gmail.com]

lib/libc/loongarch/gen/setjmp.S

85–88

What setjmp/longjmp saves are the callee-saved registers, not the floating-point environment. fcsr0 also contains exception status bits, and restoring the whole register would wipe out floating-point exceptions raised after setjmp, so it is suggested to remove this.

152–155

What setjmp/longjmp saves are the callee-saved registers, not the floating-point environment. fcsr0 also contains exception status bits, and restoring the whole register would wipe out floating-point exceptions raised after setjmp, so it is suggested to remove this.

163

Suggested change to:

ret