This is the mail archive of the
mailing list for the glibc project.
Re: RISC-V: _init and _fini vs array variants
- From: Palmer Dabbelt <palmer at sifive dot com>
- To: Jim Wilson <jimw at sifive dot com>
- Cc: fweimer at redhat dot com, libc-alpha at sourceware dot org, binutils at sourceware dot org, dj at redhat dot com
- Date: Thu, 02 Aug 2018 09:01:41 -0700 (PDT)
- Subject: Re: RISC-V: _init and _fini vs array variants
On Fri, 22 Jun 2018 11:25:48 PDT (-0700), Jim Wilson wrote:
On 06/22/2018 06:35 AM, Florian Weimer wrote:
RISC-V doesn't have _init and _fini, it seems. At least the glibc code
avoids calling these functions for main programs even if they are defined.
Are they simply undefined, or are they defined and repeated in the array?
Could we use a weak reference in generic code to simplify things?
I also notice that the dynamic loader, for shared objects, still looks
for DT_INIT and DT_FINI. Presumably, this is harmless because they are
never present on RISC-V?
I don't know the history of this particular decision in the RISC-V port,
but init_array has been preferred over init for a long time. You can
stack unwind/throw exceptions through init_array, but not init for
instance. GCC switched from init to init_array a while ago for this and
The rationale is pretty much as you guessed: we don't have any legacy init/fini
based systems so we just don't provide init/fini.
As a new target, RISC-V has no old compilers that need init, and hence
there should be no need for glibc to support it. Supporting init means
some extra code in the crt files, and some extra cycles at program
startup running the extra code. It would be nice if we can avoid that.
The no-init glibc support was added in 2013
Looking at the patches, I see that they agree with what I said, new
targets should not need the overhead of supporting init.
The fact that DT_INIT and DT_FINI are still used looks like a harmless
oversight in the original patch adding this support. I'd suggest filing
a glibc bug report for that.
It does look like RISC-V is the only target using this support, which
means we will be finding code that has unnecessary dependencies on the
Do you have something specific that requires _init? The Fedora distro
has gotten pretty far along in their builds, and I haven't seen any
report of problems with the missing _init. Likewise, Debian and OpenSuse.