Hi Florian,
On 2/20/20 10:48 AM, Florian Weimer wrote:
> * Andreas Schwab:
>
>> environ is empty.
>
> 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).
>
> This should fix the breakage:
>
> Subject: Use ELF constructor instead of _init in libc.so
>
> On !ELF_INITFINI architectures, _init is no longer called by the dynamic
> linker. We can use an ELF constructor instead because the constructor
> order does not matter. (The other constructors are used to set up libio
> vtable bypasses and do not depend on this initialization routine.)
>
> diff --git a/csu/init-first.c b/csu/init-first.c
> index 1cd8a75098..1fa1633657 100644
> --- a/csu/init-first.c
> +++ b/csu/init-first.c
> @@ -46,9 +46,8 @@ __libc_init_first (int argc, char **argv, char **envp)
> /* For DSOs we do not need __libc_init_first but instead _init. */
> }
>
> -void
> -attribute_hidden
> -_init (int argc, char **argv, char **envp)
> +static void __attribute__ ((constructor))
> +init (int argc, char **argv, char **envp)
> {
> #endif
>
This (or lack thereof) turned out to be the nasty busbox sh crash (and kernel init
panic) on ARC based off rebased upstream (latest RV32 from Alistair) containing
the original patch f4349837d93b4df. I tried this fixup and it seems to work. The
DT_INIT entry goes away and init does run as part of init_array.
It seems that commit also removed init_array from sysdeps/{riscv,csky}/Implies -
so newer arches. I suppose I need to do that for ARC as well - but could you
please explain (or point to documentation) which explains how this the Implies
stuff works.
> But I'm no longer sure if RISC-V is actually an !ELF_INITFINI
> architecture.
And an arch is !ELF_INITFINI if it supports initarray ?
I did switch ARC gcc [1] / binutils [2]to initarray last year
[1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-January/005318.html
[2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-February/005388.html
Thx,
-Vineet
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
