[PATCH 1/1] sandbox: add symbol _init for RISC-V compilation

[Jim Wilson]

On Thu, May 13, 2021 at 5:55 PM Bin Meng <bmeng.cn at gmail.com> wrote:

> On Fri, May 14, 2021 at 7:56 AM Simon Glass <sjg at chromium.org> wrote:
> > On Thu, 13 May 2021 at 08:46, Heinrich Schuchardt <xypron.glpk at gmx.de>
> wrote:
> > >     /usr/bin/ld: common/built-in.o: in function `bootdelay_process':
> > >     common/autoboot.c:335: undefined reference to `_init'
> > >     collect2: error: ld returned 1 exit status
> > >     make: *** [Makefile:1726: u-boot] Error 1
>

In the ELF standard, .init sections were deprecated and replaced with
.init_array sections in the early 1990s I think.  It took some time for the
toolchains to fully migrate from init to init_array, but by 2010 or so
everyone was using init_array instead of init, with init support retained
only for legacy code that hadn't been fixed to use init_array yet.  Because
RISC-V is a new target with no legacy code to support, we made the decision
to drop support for the obsolete init section.  Last I checked there are
only two glibc targets that have no init section support, with the other
one also being a new arch, like RISC-V.  Same goes for the embedded target,
so the RISC-V newlib port has no init section support also.

It sounds like you have some legacy user code that hasn't been fixed yet to
use init_array instead of init.  Or maybe it is a program loader that
supports both?  In which case it should be extended to not use init on new
targets that no longer support it.

Init_array supports stack unwinding (aka C++ EH) and init doesn't, so
init_array should always be preferred over init, unless you have a very old
toolchain that lacks init_array support.  Dropping init support from the
RISC-V toolchain allows us to save some bytes of program code size, and
save some cycles on program startup, which is good considering that this is
a feature that we don't need anymore.

Jim