On 22/04/2022 17:29, Steffen Huber wrote:
> Hi,
>
>> Rob Kendrick <rjek@rjek.com> wrote:
> [snip]
>> Is building code for ARMv3 (or v4?) supported and I'm being an idiot, or
>> is this totally out of scope of the endeavour?
>
> No idea about the GCCSDK details, but from a GCC-ARM-backend perspective,
> ARMv4 and everything-non-Thumb-before-ARMv6 was deprecated I think in
> GCC 6, so I guess it was removed from the ARM backend in one of the
> later versions.
Certainly, ARMv4 (no T) is still deprecated in GCC 13. Support remains,
however (my understanding is that removing it will necessitate removing
support for various StrongARM variants and there was push-back against
that when all the other non-Thumb architecture variants were removed in
2018). So, in practice, it's still there, is understood, and produces
the code you would expect.
[Aside: you could still probably get away with using ARMv4T here anyway
and building all the compilation units in ARM mode as no interworking is
actually necessary].
[...]
> So unless you re-add the support to the ARM backend, I guess you
> are out of luck and need to go back to GCC 4.7.x for old ARM
> architecture compatibility.
There is still one gotcha if you want to support Acorn hardware: the
RiscPC bus doesn't support halfword (16bit) accesses, so LDRH/STRH do
not work. Teaching the compiler not to emit these instructions turns out
to be fairly trivial, however.
Some time ago, we put all of this together to produce a GCC10-based
toolchain that will build for ARMv4 (using softfloat) and using EABI
calling conventions. The resulting binaries (whether statically or
dynamically linked) require ARMEABISupport and so require RISC OS 5
(unless I've misinterpreted ARMEABISupport's use of the PMP dynamic area
APIs). In terms of hardware compatibility, StrongARM RiscPCs are the
minimum thing supported (as ARMv4 is the minimum supported architecture,
all ARM610/710/7500(FE)-based systems are ruled out but all other
post-Acorn systems should be fine).
The full set of changes can be found at:
https://git.netsurf-browser.org/toolchains.git/tree/arm-riscos-gnueabi/
and the commit messages are probably reasonably instructive as to what
is changing and why:
https://git.netsurf-browser.org/toolchains.git/log/arm-riscos-gnueabi
(The squash-merge introducing the toolchain is disaggregated here:
https://git.netsurf-browser.org/toolchains.git/log/?h=jmb/arm-riscos-gnueabihf
in case that's of use to anyone)
As implied by the directory name, the system triplet
(arm-riscos-gnueabi) differs from the arm-riscos-gnueabihf used by the
GCC10 in the autobuilder (as the ABIs are *not* compatible -- the "hf"
one requires ARMv7 and VFP hard float). This is reasonably analogous to
the Debian armel/armhf architecture split, so should not be unreasonably
confusing.
John Tytgat's original GCCSDK makefile was resurrected as part of this
work, so it builds in pretty much the same way as the GCC 4-based GCCSDK
does (which much better fits the NetSurf toolchain requirements than the
rules in the autobuilder).
Most of the other patches should be fairly obvious (the POSIX locales
one was upstreamed aeons ago, so is already in UnixLib proper). There
are probably two items that deserve special mention:
1. elf2eif has had some significant surgery to ensure that static
binaries using EABI work properly:
a: enabling ARMEABISupport's abort handling at process start
b: ensuring that the GOTT_BASE pointer at &8038 is filled in
2. UnixLib's stack unwinding has been reworked significantly for the
EABI case (and refactored in the APCS case). Successful EABI unwinding
requires the presence of unwind tables (i.e. building with
-funwind-tables), however.
Hopefully this is of use to somebody!
John-Mark.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
No comments:
Post a Comment