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

[Sebastian Huber]

On 26/07/18 22:12, Jim Wilson wrote:
> 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.

glibc has a more sophisticated configuration machinery than Newlib. I 
think in Newlib there exists currently no generic mechanism for machines 
(architectures) to define options for the generic code. They can only 
overwrite/replace files via the build system. Since machine defines are 
already used throughout the Newlib code base, I will prepare a patch 
using this approach. I think a configuration script detection is less 
obvious and harder to understand.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.