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

Sebastian Huber <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>

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  : [email protected]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.