[PATCH v2 5/5] Linux: Consolidate auxiliary vector parsing

[Szabolcs Nagy]

The 02/11/2022 11:17, Adhemerval Zanella wrote:
> On 11/02/2022 10:49, Florian Weimer wrote:
> > * Szabolcs Nagy:
> >> The 02/11/2022 09:47, Adhemerval Zanella wrote:
> >>> On 11/02/2022 09:31, Szabolcs Nagy via Libc-alpha wrote:
> >>>> The 02/03/2022 12:08, Florian Weimer via Libc-alpha wrote
> >>>>> +  dl_parse_auxv_t auxv_values = { 0, };
> >>>>> +  _dl_parse_auxv (av, auxv_values);
> >>>>
> >>>> this seems to use memset now on aarch64 before irelative
> >>>> relocs are resolved in static binaries.
> >>>>
> >>>> which causes infinite loops in the iplt (i've also seen
> >>>> segfaults in the build log).
> >>>>
> >>>> i wonder what is a clean fix...
> >>>>
> >>>
> >>> Maybe add inhibit_loop_to_libcall to avoid the memset call.
> >>
> >> does not work for me..
> >> happens at -O0 too
> >> https://godbolt.org/z/W9r3nffYd
> > 
> > Seems to happen with -fno-builtin or -ffreestanding as well.  It's a GCC
> > bug, but I'll investigating working around it.
> 
> I don't think it is gcc bug, even for -ffreestanding compiler can assume
> the C environment will always provide memset/memcpy.  The problem is we
> need a gcc option to avoid such optimization, which afaik there is none.
> 
> And without such option I think we will need to either revert this change
> or use the symbol alias strategy to avoid using IFUNC on loader code.

if we can rewrite the code not to depend on zeroing a large array
(where large is about >200bytes) that should work too.

i dont see a clean way, but e.g. a

char seen_auxval[AT_MINSIGSTKSZ+1] = {0};

would not trigger memset (on aarch64).

as a bonus with such an array we can distinguish auxv unset and auxv 0.