Re: RISC-V: GCC crti.S vs. Newlib __libc_init_array()

[Jim Wilson <jimw at sifive dot com>]

On 07/25/2018 03:02 AM, Sebastian Huber wrote:
> the GCC provided libgcc/config/riscv/crti.S and 
> libgcc/config/riscv/crtn.S files are empty on RISC-V, e.g. they contain 
> no definitions of _init and _fini. This leads to undefined references in 
> Newlib provided __libc_init_array() and __libc_fini_array(). I would 
> like to fix this. Should this be done via some configure test or a 
> __riscv machine define in newlib/libc/misc/init.c and 
> newlib/libc/misc/fini.c?

RISC-V is a new target.  It does not need support for the deprecated 
_init and _fini functions.  It supports _init_array and _fini_array 
only.  Glibc has generic support for disabling _init/_fini for targets 
that don't need it which is used by the RISC-V glibc port.  Newlib 
should have something similar.  In the glibc case, you put init_array in 
sysdeps/$cpu/Implies.  In the newlib case, we probably need something we 
can define in newlib/configure.host, to tell newlib not to use _init or 
_fini, and then newlib/libc/misc/{init,fini}.c don't call the functions 
when this is defined.

Though it is curious that this didn't come up before, so poking around, 
I see that the libgloss/riscv/crt0.S has its own definitions of _init 
and _fini that have the same address, and contain only a ret 
instruction.  This is 2 extra bytes of code we don't need, plus a bunch 
of symbols.  This should be removed if/when newlib has generic support 
for disabling the deprecated _init and _fini functions.

Jim