summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* arm-riscos-gnueabi: update squeezejmb/arm-riscos-gnueabihfJohn-Mark Bell2023-03-051-1/+1
| | | | | Picks up Makefile changes that understand more than arm-unknown-riscos. No functional change, however.
* SDK: follow arm-riscos-gnueabi triplet renameJohn-Mark Bell2023-03-054-5/+5
|
* Patch upstream patches to match arm-riscos-gnueabiJohn-Mark Bell2023-03-051-0/+100
|
* Drop "hf" from arm-riscos-gnueabihf ABI tripletJohn-Mark Bell2023-03-0525-10/+10
| | | | | | | The way we configure this toolchain means that it will generate Risc PC-compatible ARMv4 binaries using the soft-float ABI. These are not compatible with the ARMv7 hard-float binaries produced by the upstream compiler, so change the triplet to avoid confusion.
* SDK/arm-unknown-riscos: poke function namesJohn-Mark Bell2023-03-051-0/+4
|
* Fix unixlib-stdtime.pJohn-Mark Bell2023-03-051-9/+0
| | | | | Previous attempt contained unrelated detritus already present in posix-extended-locale.p
* Fix __standard_time()John-Mark Bell2023-03-051-0/+26
| | | | | | | | | Territory_ConvertDateAndTime modifies r0-r3. Previously, UnixLib was only telling the compiler that r0 and r1 were modified. This resulted in the register allocator assuming that the value of r2 on exit was the same as it was on entry and thus returning a completely garbage value as the result of __standard_time(). Resolve this by telling the compiler the full facts.
* Use UnixLib's atomics implementationJohn-Mark Bell2023-03-052-0/+78
| | | | | | | | | | | Stop libgcc pulling in the atomics implementation for Linux. This does not work on RISC OS and will result in unexpected aborts deep in application code. Additionally, enable the __sync_fetch_and_<op>_<size> atomics when building UnixLib for EABI. It's not clear why these were disabled, but things that need them will fail to link if they are not present.
* Revert "Fix stack backtraces from UnixLib"John-Mark Bell2023-03-051-37/+0
| | | | | | | | | | | | | | This reverts commit 7f53178a4cdbed363328a5fa60bead742bd628aa. It turns out that the situation with stack frames in the EABI toolchain is currently completely inconsistent. Some functions end up with APCS-32 stack frames, others with AAPCS frames. It is not reliably possible to distinguish which is which when unwinding the stack to generate a backtrace. It also means that the signal stack frame created in _signal.s would need to reflect whatever reality made sense for the function that aborted. Give up.
* Fix stack backtraces from UnixLibJohn-Mark Bell2023-03-051-0/+37
| | | | | | The frame pointer to the signal stack frame was off-by-one resulting in unwinding terminating early. Additionally, we can dump the register state at the point of the abort now.
* Teach elf2aif to handle EABI binariesJohn-Mark Bell2023-03-052-16/+110
| | | | | | | | | | | | | | | | | | | | | | | | The previous attempt was bogus as elf2aif is built for the system that the cross compiler runs on and thus __ARM_EABI__ would only be set if the cross compiler was built for an ARM-based system. Further, removing the OSABI check completely is fragile, so let's not do that. Instead, we introduce a new command line option for elf2aif which must be specified if processing EABI binaries. This alters the OSABI check to test for SysV, rather than ARM in the EABI case. Additionally, correct functioning of ARMEABISupport is reliant on the application loader to cause the ARMEABISupport abort handler to be installed. For ELF binaries, this is ensured by SOManager. For AIF binaries, however, RISC OS itself knows nothing about ARMEABISupport and thus will not ensure that the abort handler is installed. Make elf2aif inject the necessary SWI call into _start (overwriting instructions that are meaningless when the binary is not loaded by SOManager). This ensures that the abort handler is installed as early in the application execution as possible (and long before any memory managed by ARMEABISupport is allocated).
* SDK build runes for arm-riscos-gnueabihfJohn-Mark Bell2023-03-054-2/+65
| | | | Follows the existing arm-unknown-riscos setup.
* Make ro-install availableJohn-Mark Bell2023-03-052-0/+19
| | | | | The OSLib buildsystem expects this to exist, so ensure it does, patching the original to find the correct objdump binary.
* Teach OSLib about EABIJohn-Mark Bell2023-03-053-1/+229
| | | | | | | | | | This introduces a new asmtype to defmod which invokes the correct GCC for the task. It may be necessary to perform further surgery to defmod's assembler generation to address places where the EABI calling conventions don't match APCS-32 (note that there is no floating point involved here, so that's one headache avoided). Update the OSLib build system to allow building for an EABI target.
* Fix OS ABI check when building elf2aif for EABIJohn-Mark Bell2023-03-051-0/+16
| | | | | | | Binaries built with the arm-riscos-gnueabihf toolchain have an OS ABI of none (i.e. Sys-V) in the ELF header. elf2aif expected the declared ABI to be ARM as that is what the previous tooling emitted. Fix up this check to reflect the new reality.
* Fetch and build additional toolsJohn-Mark Bell2023-03-052-7/+39
| | | | Specifically: asasm, elf2aif, ln, mkres
* Don't pull in ARMv7-specific memcpy() and friends.John-Mark Bell2023-03-051-0/+34
| | | | | | Hiding this behind ARM_EABI probably isn't the complete answer as the calling convention doesn't have much to say about the platform the end result is run on.
* Fix initial stack allocation for EABI and soft FP.John-Mark Bell2023-03-051-0/+31
| | | | | | | | | | | | | | | | | In this case, there are no VFP registers to reserve space for at the top of the application stack. Thus, the stack pointer points at the top of the stack when we ask ARMEABISupport to give us the stack handle. Unfortunately, despite the top address being given to us by ARMEABISupport in the first place, it does not consider the top of the stack to be part of the stack's storage space and thus we fail to obtain our stack handle and the application aborts. Work around this by discarding the top N bytes of the stack when EABI and soft FP are active. The resulting stack pointer will be aligned to a multiple of 8 bytes in the usual way for AAPCS. Additionally, resolve another stack imbalance in an error path that was spotted while working through this.
* Build riscos-ld for armv4John-Mark Bell2023-03-051-0/+13
|
* Disable halfword accesses by default.John-Mark Bell2023-03-051-0/+13
| | | | | | | | | | | | We don't want these at all until such time as we drop support for the Risc PC. Due to the unique way that its bus operates (it was designed for armv3 parts), 16bit accesses fail horribly, even if the CPU supports armv4 (like StrongARM does). Disabling this by default ensures that everything built by this toolchain should run happily on such systems (unless someone explicitly opts in to LDRH/STRH generation by passing -mhalfword-accesses). Note that other armv4 access instructions (such as LDRSB) are not affected by this option at all.
* Add a -mhalfword-access flag to GCC.John-Mark Bell2023-03-051-0/+153
| | | | | This defaults to "on", as that's what most sane people want when building for armv4 or later.
* Patch UnixLib to build for armv4 when using EABI.John-Mark Bell2023-03-051-0/+80
| | | | | | | | | | | | | | | | There are a few places where a decision is made at runtime as to which atomic operations to perform. Modern gas objects to this scheme if it isn't told about it, resulting in errors from the assembler and failed builds. Tell gas what we're doing and make the SWP-present logic depend on the architecture that UnixLib is being built for (if you build for armv6 or later in EABI mode, then no runtime decision or SWP instructions will be emitted). Additionally, there's a similar case where LDREX/STREX is used from inline assembler in the __cmpxchg atomic built when targetting EABI. Make this, too, conditional on building for armv6 or later.
* Make config.sub identify RISC OS; libtool follows.John-Mark Bell2023-03-052-0/+130
| | | | | | The logic in libtool.m4 looks somewhat confused. This is a direct translation of what was there already to the new world. It may need further changes to work reliably.
* "Fix" FTBFS: disable maintainer mode for binutils.John-Mark Bell2023-03-051-1/+1
| | | | | | | | | | Enabling maintainer mode causes bfd-in2.h to be regenerated from bfd-in.h. This results in the "riscos_module" field in the elf32_arm_params to be wrapped in #ifdef __RISCOS_TARGET___. While this is defined when bfd itself is built, it is not defined when ld is compiled, resulting in a failure to compile earmelf_riscos_eabi.c (as it expects to be able to address that parameter.
* First cut at GCC 10/arm-riscos-gnueabihfJohn-Mark Bell2023-03-0510-0/+2799
|
* SDK/libcurl: drop patches merged upstreamJohn-Mark Bell2023-03-056-1241/+0
|
* SDK: bump library versionsJohn-Mark Bell2023-03-051-6/+6
|
* SDK: bump OpenSSL to 3.0.8John-Mark Bell2023-03-051-1/+1
|
* libexpat/m68k-unknown-amigaos: explicit -lgccJohn-Mark Bell2022-11-031-1/+4
| | | | | | For whatever reason (and this really should not be necessary), linking will fail without doing this as libgcc gets evaluated by ld after libm, and thus cannot resolve the symbols it needs.
* libexpat/m68k-unknown-amigaos: patch out strtoullJohn-Mark Bell2022-11-032-2/+14
| | | | | | | For whatever reason the libc in the toolchain does not provide this (despite there being an implementation available). This results in the xmlwf too failing to link. Work around this by replacing strtoull with strtoul.
* m68k-unknown-amigaos: use OpenSSL in lieu of a modern AmiSSLJohn-Mark Bell2022-11-031-5/+14
| | | | Rework the logic here so it's less hard to switch between them.
* libcurl/m68k-unknown-amigaos: remove redefinition of __NO_NET_APIJohn-Mark Bell2022-11-031-0/+10
|
* libcares/m68k-unknown-amigaos: add IPV6 patchJohn-Mark Bell2022-11-031-0/+67
|
* OpenSSL/m68k-unknown-amigaos: refresh patchesJohn-Mark Bell2022-11-0311-277/+337
|
* m68k-unknown-amigaos: define RLIMIT_NOFILE for iconvJohn-Mark Bell2022-11-031-1/+1
| | | | | This is unlikely to be the correct answer here, however (as who knows if getrlimit() actually works on this platform)
* libiconv/m68k-unknown-amigaos: refresh patchesJohn-Mark Bell2022-11-033-8/+12
|
* libcurl/ppc-amigaos: refresh patchesJohn-Mark Bell2022-11-034-100/+30
|
* c-ares/ppc-amigaos: no IPv6 support in stdlibJohn-Mark Bell2022-11-032-11/+66
|
* OpenSSL/ppc-amigaos: rework entropy gathering for OpenSSL 3John-Mark Bell2022-11-024-191/+287
|
* OpenSSL/ppc-amigaos: avoid broken stdatomic.hJohn-Mark Bell2022-11-021-0/+22
| | | | | | | | | For whatever reason, when the toolchain is built against newlib, GCC does not provide stdint.h, and thus does not pre-define the likes of __INT_LEAST8_TYPE__ or __UINTPTR_TYPE__. Thus, including stdatomic.h (which expects these to be defined) fails hard. Drop this if ever the toolchain is fixed.
* OpenSSL/ppc-amigaos: refresh patchesJohn-Mark Bell2022-11-029-52/+93
|
* SDK/libiconv: refresh patchesJohn-Mark Bell2022-11-029-13/+13
|
* sdk: libcurl: Significantly faster https connectionsMichael Drake2022-11-026-0/+1241
| | | | | | | | | | | | | | Making HTTPS connections was slow because libcurl forces openssl to rebuild the same X509_STORE from the same cabundle every time a connection is made. This is a slow process and it can happen many times per page. These patches change libcurl to keep the built X509_STORE cached and reuse it for subsequent connections. These patches are being upstreamed here: https://github.com/curl/curl/pull/9620
* SDK: bump library versionsJohn-Mark Bell2022-11-011-6/+6
|
* SDK: bump OpenSSL to 3.0.7John-Mark Bell2022-11-011-1/+1
|
* Extend POSIX locale patch to cover most APIsJohn-Mark Bell2022-05-301-27/+595
| | | | The only missing one that's defined by POSIX is strftime_l.
* OpenSSL: drop unnecessary patchJohn-Mark Bell2022-05-301-11/+0
|
* UnixLib: add POSIX extended locale supportJohn-Mark Bell2022-05-301-0/+1352
| | | | | This is not a complete implementation, but is sufficient for OpenSSL3's purposes.
* arm-unknown-riscos: fetch GCC sources as a tarballJohn-Mark Bell2022-05-281-0/+11
|
* arm-unknown-riscos: update to 4.7.4r6John-Mark Bell2022-05-287-488/+9
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-19 04:26:01 +0000