RISCOS: Investigate support for building with EABI toolchains?

[ccawley2011]

Using an EABI based toolchain would allow (among other things) building with GCC 10 instead of GCC 4.7, however it currently only supports ARMv7 targets, which excludes the RiscPC, the Iyonix, the A9home, the Raspberry Pi 1 and current emulators of RISC OS machines, which is a dealbreaker for me.

The NetSurf developers have a WIP ARMv4 compatible version of the EABI toolchain, but from what I've heard it's not ready for production use.

[ccawley2011]

Some info from the NetSurf IRC channel so that I don't forget about it:

<tlsa> jmb: what's the state of play with arm-riscos-gnueabihf
<jmb> it works, but you don't want to use it
<tlsa> why?
<jmb> a) the abi triplet needs renaming (it does not produce output compatible with the real hard-float compiler)
<jmb> b) stack unwinding is utterly broken (by design -- the only way to unwind now is with additional unwind data)
<jmb> c) the toolchain produces a bogus mishmash of APCS-32 and AAPCS function pre/postambles
<tlsa> b just affects our crash logging?
<jmb> I believe what's there is just dangerous
<tlsa> ah
<jmb> but yes, providing it doesn't run off into the weeds

(later...)

<jmb> tlsa: that's (a) fixed
<jmb> (I've renamed it arm-riscos-gnueabi, which aligns with the Debian armel/armhf triplet names)
<jmb> in theory, the only thing needed for a gnueabihf build is a suitable toolchain (which can drop a bunch of the compatibility patches that the gnueabi toolchain needs)
<jmb> (both the core buildsystem and NetSurf's will dtrt in either case)
<jmb> note that I've not shoved an ARMEABISupport binary in the RO distribution because a) I only have one I built myself, which is hardly controlled and b) I can find no actual licensing information for it
<jmb> sources are here: ​https://www.riscos.info/websvn/listing.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Friscos%2Farmeabisupport%2F
<tlsa> Nice!
<tlsa> There's an unwinding commit too
<tlsa> Is that b or was there more to it?
<jmb> that just adds the metadata
<jmb> there's no code in unixlib to look at it
<tlsa> ah, like libunwind?
<jmb> yeah
<jmb> but not libunwind as that makes assumptions (and explodes violently if they're not met -- I've already stepped on that landmine)
<tlsa> heh
<jmb> ​https://paste.rs/LXL contains something that basically "works", but would need transplanting into unixlib
<tlsa> oh, cool