| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This wasn't relevant to the AmiSSL change and should have been left alone.
|
|
|
|
|
|
|
| |
libcurl+OpenSSL+NetSurf doesn't connect to secure sites under OS3.x.
Confirmed libcurl+AmiSSL (v5.13)+NetSurf, along with Miami,
is a working combination under AmigaOS 3.2.2.1
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
At present, there is no released version of lhasa that can cope
with the mis-encoded empty directories in the LHAs in SDK 54.16.
Fetch the fixed lhasa sources from git and build them instead of
using whatever (broken) version is installed on the builder.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lose 2 instructions (or 25%) from the entrycode by injecting
PC-relative instructions to compute the address of the GOT pointer
and store it into the "well known" GOTT_BASE at &8038.
This does make the relocation code somewhat larger, but there is
no space limitation there, so it's less likely to break. (The
requirement for at least 3 ELF program headers still remains as,
even with this reduction in entrycode size, it's still 16 bytes
larger than the space that would be available with 2 program
headers).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous approach, as noted, would fail if the OS marked the
ROdata section readonly and also relied on collusion between
elf2aif and UnixLib. Instead, take a different approach which
removes the collusion and which will also work if the ROdata
section is not writeable: append relocation code to the end of
the image and ensure it is run before the zero-initialisation
code runs. By design (and the AIF specification), the ROdata
section _must_ be writeable when the relocation code runs, so
we can guarantee that it is safe to write things from it.
One wrinkle is that DDT makes use of the same location as the
optimised "well-known" GOTT_BASE location (&8038). There is an
unsatisfactory workaround for this scenario.
Note also that we are exceptionally tight on space for the
entrycode (in fact, if there are fewer than 3 program segments
in the ELF image, there are only 8 bytes remaining after the AIF
header, which is barely sufficient for anything). Fortunately,
we know this toolchain will emit at least 3 program headers so
this scheme is safe enough. If we ever need more space for the
entrycode, the obvious solution is to have the various
implementations of _start (found in the crt/*crt*.s files in
the UnixLib sources) begin with sufficient NOPs for elf2aif
to inject the entrycode into.
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we're generating a traceback as the result of an environment
handler being invoked, there may well be a stored abort block
to inspect. Dump the registers it contains and disassemble the
code at the point of explosion, as for non-EABI builds.
Note, however, that at present, ARMEABISupport gobbles data aborts
so they end up appearing via the Error handler and thus no abort
block is available. This does mean that invalid data accesses no
longer produce useful stack traces.
|
| |
|
| |
|
| |
|
|
|
|
| |
This does require the presence of unwind tables, however.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Non-PIC (static) binaries may still link against PIC library code
and so require the GOT to be discoverable. Now that it is expected
to be found via the runtime workspace entry at &8038, we must
ensure that static binaries converted to AIF using elf2aif behave
correctly.
Unfortunately, this scheme will fallover if ever the OS makes the
text segment read-only (as &8038 is in the middle of the AIF
header, so cannot have GOTT_BASE baked in at conversion time).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Squashed commit of the following:
commit a0966d9ac38b7efa6c0bbb0994daee001126ac10
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Thu Nov 3 21:19:26 2022 +0000
arm-riscos-gnueabi: update squeeze
Picks up Makefile changes that understand more than
arm-unknown-riscos. No functional change, however.
commit 7f0fa52027ace273ab5d7227d14a4be749cbc250
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Thu Nov 3 19:37:32 2022 +0000
SDK: follow arm-riscos-gnueabi triplet rename
commit dcfea919e2fe4677bad0d92b308ff0326e056d65
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Thu Nov 3 19:34:26 2022 +0000
Patch upstream patches to match arm-riscos-gnueabi
commit 525ecd97ac5b445ea7a61a34c581efa613bd8385
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Thu Nov 3 19:31:20 2022 +0000
Drop "hf" from arm-riscos-gnueabihf ABI triplet
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.
commit 6172d5deb9181c9adf0653a336deadaf830bf416
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Tue Nov 1 20:02:44 2022 +0000
SDK/arm-unknown-riscos: poke function names
commit a8dda8698a3176a53e37ec1a247b208254f47504
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Sun Jun 5 20:08:39 2022 +0100
Fix unixlib-stdtime.p
Previous attempt contained unrelated detritus already present in
posix-extended-locale.p
commit 17154570d6c6f16dc031603728db07cae081ef18
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Sun Jun 5 19:58:38 2022 +0100
Fix __standard_time()
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.
commit c675a0029ddca4617c68d792bff5516ad5faf418
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Fri Jun 3 23:30:54 2022 +0100
Use UnixLib's atomics implementation
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.
commit a81418bfbd348d3adb63b286923adef3c5a7ad6f
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Fri Jun 3 23:27:50 2022 +0100
Revert "Fix stack backtraces from UnixLib"
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.
commit ebbf5913513c2cffc850f48510bcf1dbd60aced3
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Fri Jun 3 20:24:10 2022 +0100
Fix stack backtraces from UnixLib
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.
commit 7b181629a1aa80dfcebcc744d0f980c133a6ab6e
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Fri Jun 3 17:45:06 2022 +0100
Teach elf2aif to handle EABI binaries
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).
commit 9fd4d4243d5e3449e72d4915269db1aa23cba831
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Thu Jun 2 20:32:30 2022 +0100
SDK build runes for arm-riscos-gnueabihf
Follows the existing arm-unknown-riscos setup.
commit 9f22af07a249f778f8a8da4306ef625e203de4ad
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Thu Jun 2 19:40:02 2022 +0100
Make ro-install available
The OSLib buildsystem expects this to exist, so ensure it does,
patching the original to find the correct objdump binary.
commit ce797f8c661d671bdb3be2b2bb78b0ff2d31d6d3
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Thu Jun 2 19:17:43 2022 +0100
Teach OSLib about EABI
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.
commit dbfc576658cf6f641ae3444b34f10441aaea1fbd
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Thu Jun 2 16:34:10 2022 +0100
Fix OS ABI check when building elf2aif for EABI
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.
commit 7785b12e408974061c60a3b7d673ab34769809cc
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Thu Jun 2 16:33:05 2022 +0100
Fetch and build additional tools
Specifically: asasm, elf2aif, ln, mkres
commit 0b97e40c9b308b135b6527fd1124d53fb1726099
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Thu Jun 2 03:32:08 2022 +0100
Don't pull in ARMv7-specific memcpy() and friends.
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.
commit bb81aa2f16039ef22c59931969bd41c1e6a2c477
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Thu Jun 2 02:01:04 2022 +0100
Fix initial stack allocation for EABI and soft FP.
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.
commit cb7a97a09c4a6e8932d0ec1ae786d904ab917e29
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Wed Jun 1 19:59:30 2022 +0100
Build riscos-ld for armv4
commit dc90f45614bfe40caf3e3b93aef55a7dfedd3da3
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Wed Jun 1 10:28:20 2022 +0100
Disable halfword accesses by default.
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.
commit 4f71aa98cf4174d5121f6348ca8b84d31f2532b4
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Wed Jun 1 10:27:09 2022 +0100
Add a -mhalfword-access flag to GCC.
This defaults to "on", as that's what most sane people want when
building for armv4 or later.
commit 3dc0c7fe56e19b23f7188c21619dfaa36e7f245a
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Wed Jun 1 09:59:33 2022 +0100
Patch UnixLib to build for armv4 when using EABI.
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.
commit 7e92f43f41287d46a20324bcc162aa4c4c01730c
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Wed Jun 1 08:04:28 2022 +0100
Make config.sub identify RISC OS; libtool follows.
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.
commit 4512fa86374a3691e181afacbca79ea71be6d649
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Wed Jun 1 05:50:18 2022 +0100
"Fix" FTBFS: disable maintainer mode for binutils.
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.
commit 58d3a5a992c535c27d9ebb3bcba97eb14b3229ea
Author: John-Mark Bell <jmb@netsurf-browser.org>
Date: Wed Jun 1 01:15:14 2022 +0100
First cut at GCC 10/arm-riscos-gnueabihf
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|