| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Picks up Makefile changes that understand more than
arm-unknown-riscos. No functional change, however.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Previous attempt contained unrelated detritus already present in
posix-extended-locale.p
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
| |
Follows the existing arm-unknown-riscos setup.
|
|
|
|
|
| |
The OSLib buildsystem expects this to exist, so ensure it does,
patching the original to find the correct objdump binary.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Specifically: asasm, elf2aif, ln, mkres
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This defaults to "on", as that's what most sane people want when
building for armv4 or later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Rework the logic here so it's less hard to switch between them.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is unlikely to be the correct answer here, however (as
who knows if getrlimit() actually works on this platform)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
The only missing one that's defined by POSIX is strftime_l.
|
| |
|
|
|
|
|
| |
This is not a complete implementation, but is sufficient for
OpenSSL3's purposes.
|
| |
|
| |
|