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

Heinrich Schuchardt xypron.glpk at gmx.de
Tue May 18 22:58:10 CEST 2021

On 5/18/21 9:29 PM, Jim Wilson wrote:
> On Thu, May 13, 2021 at 5:55 PM Bin Meng <bmeng.cn at gmail.com
> <mailto:bmeng.cn at gmail.com>> wrote:
>     On Fri, May 14, 2021 at 7:56 AM Simon Glass <sjg at chromium.org
>     <mailto:sjg at chromium.org>> wrote:
>      > On Thu, 13 May 2021 at 08:46, Heinrich Schuchardt
>     <xypron.glpk at gmx.de <mailto: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.

I am compiling the sandbox_defconfig target of upstream U-Boot with GCC
11. Please, indicate what "legacy user code" you are referring to.

Best regards


> 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

More information about the U-Boot mailing list