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.