This was a quite common trick to able to load executables with a.out
headers stripped. Now, the system boots successfully into multi-user
mode without this trick.
Thanks ragge@ for kind explanation:
https://mail-index.netbsd.org/port-vax/2023/07/28/msg004397.html
These changes should make no practical effect - but because external
data is being examined, it would be possible to contrive a situation
(perhaps) where uninit'd vars could actually be used (unless the format
has been checked elsewhere earlier - I did not look ... we have to
appease gcc anyway).
Joerg: Please review (& fix)
The basic glue works with mininal changes for other architectures as
well, but those require linker changes first to avoid leaking dynamic
relocations into the binary.
into a header for reuse in crt0.o for static ifunc support. Change the
existing logic for sparc64 to use the Bicc variant of ba,a as it allows
+-8MB displacement compared to the BPcc variant's +-1MB. Teach the sparc
variant the same trick for using ba,a and not sethi+jmp when possible.
cannot alias with an extern. While this is clearly bogus, avoid yet
another alias handling bug and use strong aliases. It's actually
slightly simpler, too.
As such, reorganize the start/end references to use a weak reference
only, if we use it to remove size knowledge. Otherwise use weak
external declarations.
__CTOR_LIST__ and __CTOR_LIST_END__ are logically the same object, but
due to the start marker, the former has to be declared as array of fixed
size. Newer GCC versions take the liberty of exploiting the UB of
accessing global objects past the end to unconditionally load zero
values in that case. Two fixes are possible:
(1) Pruning via inline assembler as done by GCC's own CRT copy.
(2) Pruning via weak references as done for linker sets.
Since the second part is known and required to work anyway, prefer this
approach. In theory, the labels could be replaced completely, except
that GNU as doesn't provide start/end symbols for sections containing
dots.
build crtbeginS.o with -O1 as GCC tries to be very smart with the
__DTOR_LIST__ as it believes it knows the size of the array at
compile time (which is not true until link time). on SPARC and
MIPS, the result was emitting a call to 0.
technically, i believe that GCC isn't "wrong" to make this choice,
as the array is declared with a well-known initialiser size in the
crtbegin.c compilation unit, and we have noticed that the libgcc
version of this code has some hacks added, most likely to avoid
being bitten by this optimisation.
this makes sshd work for me on earm and sparc with GCC 5.
christos