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