Re: [PATCH] Introduce <elf-initfini.h> and ELF_INITFINI for all architectures

[Jim Wilson <jimw at sifive dot com>]

On Thu, Feb 20, 2020 at 10:53 AM Florian Weimer <fweimer@redhat.com> wrote:
> That's because libc.so.6 still has DT_INIT, from which _environ and
> other variables are set up.  I assumed binutils would convert that into
> DT_INITARRAY because the architecture is not supposed to have DT_INIT.
> Without that, it's hard to declare that there is no DT_INIT, and the
> patch essentially breaks ABI (because DT_INIT processing is gone).

DT_INIT is a function address.  DT_INITARRAY is a pointer to a table
of addresses.  I don't see how the linker can easily convert between
them.  We would have to increase the size of the init_array table at
link time, and I don't think we have any linker support for that.
Maybe we could modify the startfiles to put a weak reference to _init
at the end of init_array, right before the zero that normally ends the
list, and fix the linker to stop creating DT_INIT for _init.  But that
sounds a little risky, and defeats the purpose of dropping support for
_init to reduce code size.  I would prefer that glibc not create an
_init function in the first place.

> But I'm no longer sure if RISC-V is actually an !ELF_INITFINI
> architecture.

gcc will not create .init sections.  Newlib does not create them or
run them in the startfiles.  The linux kernel does not run DT_INIT.
That is probably why your patch failed for Andreas.

But there is a problem with GNU ld which automatically creates DT_INIT
when it sees a function called _init.  We missed that.  This is in
target dependent code.  The default function name can be overridden
but that isn't quite right for RISC-V either.  Maybe we should give a
linker error if someone gives a _init or _fini function to the linker?
 That way they get a link time error instead of a run-time error.

Jim