RISC-V: _init and _fini vs array variants

RISC-V: _init and _fini vs array variants

[Florian Weimer]

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?

Thanks,
Florian

Re: 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

Re: RISC-V: _init and _fini vs array variants

[Florian Weimer]

On 06/22/2018 08:25 PM, Jim Wilson wrote:

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

Thanks for confirming that.

The design with the sysdeps directory doesn't lend itself easily to 
fixing that because it does not scale well with the number of files that 
need special logic.  But I've got a patch and hope to submit it soon.

Thanks,
Florian

Re: RISC-V: _init and _fini vs array variants

[Palmer Dabbelt]

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

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