This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Introduce <elf-initfini.h> and ELF_INITFINI for all architectures
On Fri, Feb 21, 2020 at 2:42 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Jim Wilson:
>
> > 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.
>
> I'm not worried about glibc here. It's easy to make glibc consistent
> with itself. The patch I posted seems to do the trick, without
> regressing anywhere else.
>
> What I don't know is whether this binutils bug has resulted in DT_INIT
> being used *elsewhere*. I don't have a RISC-V distribution to analyze,
> so I really don't know. Fedora RISC-V seems dead, this hasn't been
> updated in a while:
>
> <https://dl.fedoraproject.org/pub/alt/risc-v/repo/fedora/rawhide/latest/riscv64/>
>
We are still alive, but the mirroring of the repository to
dl.fedoraproject.org was disabled.
I will look into enabling it again.