Re: RISC-V: GCC crti.S vs. Newlib __libc_init_array()
Jim Wilson <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
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