This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: RISC-V: GCC crti.S vs. Newlib __libc_init_array()
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.