libc: Fix longjmp/_longjmp(buf, 0) for AArch64, MIPS and RISC-V

[jrtc27]

Summary

All three of these architectures fail to handle this special case, and
will cause the corresponding setjmp/_setjmp to return 0 rather than 1.
Fix this and add regression tests (also committed upstream).

[jrtc27]

lib/libc/mips/gen/setjmp.S

224 ↗

(On Diff #86107)

This file is full of sadness wrt delay slots; they're not exposed here (despite being exposed in _setjmp.S!), but you would be forgiven for thinking otherwise when looking at most (but not all) of the existing branches...

[jrtc27]

NB: Tests upstreamed: http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libc/setjmp/t_setjmp.c.diff?r1=1.2&r2=1.3&only_with_tag=MAIN&f=h

[arichardson]

This looks good to me but probably best to wait until someone else has had a look.

[jhb]

Are the in-kernel impls also broken?

[jrtc27]

In D29363#657983, @jhb wrote:

Are the in-kernel impls also broken?

Interesting question with an interesting answer:

• amd64 - Hard-coded return value of 1
• arm - Hard-coded return value of 1
• arm64 - Returns argument without handling 0 properly
• i386 - Hard-coded return value of 1
• mips - Hard-coded return value of 1
• powerpc - Hard-coded return value of 1
• riscv - Returns argument without handling 0 properly

So every architecture is wrong. Gah.