RISC-V: _init and _fini vs array variants

[Jim Wilson]

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 
other reasons.

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
     https://sourceware.org/ml/libc-alpha/2013-02/msg00604.html
     https://sourceware.org/ml/libc-alpha/2013-03/msg00322.html
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 
obsolete _init.

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.

Jim