Add AT_HWCAP2 ELF auxiliary vector.

[mmel]

Summary

• allocate value for new AT_HWCAP2 auxiliary vector on all platforms.
• expand 'struct sysentvec' by new 'u_long *sv_hwcap2', in exactly same way as for AT_HWCAP.

MFC after: 1 month

[kib]

lib/libc/gen/auxv.c

223 ↗

(On Diff #34058)

I do not follow the motivation of fetching the aux values into the variables and then again parsing the AT_XXX indexes to find which variable to fetch. Why not return raw value from the aux vector with the corresponding AT_XXX name, directly ?

[mmel]

lib/libc/gen/auxv.c

223 ↗

(On Diff #34058)

Because of data types. AT_HWCAP's are ulong's, rest are int's. I can sort this case by returned data type then use _elf_aux_info(), if you find this more appropriate.

[kib]

lib/libc/gen/auxv.c

223 ↗

(On Diff #34058)

What are ints ? The return type of getauxval() is u_long, and Auxinfo.a_val has the long type.

[mmel]

My exp-run for selected ports just ended and It found unexpected problem.
Some ports detect getauxval() presence and if is present then expect that all (linux specific) AT_ flags are defined and implemented (e.g. security/p11-kit ).

I don't want to emulated full Linux behavior here, so it's time for plan B
As alternative we can make _elf_aux_info() public (as elf_aux_info()). If is this acceptable, can you please suggest me best/suitable header for this function?
Is (new) auxv.h still OK?

This approach result to slightly bigger patches for ports (that getauxval), but it's still acceptable I think.

[kib]

In D12699#263852, @meloun-miracle-cz wrote:

My exp-run for selected ports just ended and It found unexpected problem.
Some ports detect getauxval() presence and if is present then expect that all (linux specific) AT_ flags are defined and implemented (e.g. security/p11-kit ).

I don't want to emulated full Linux behavior here, so it's time for plan B
As alternative we can make _elf_aux_info() public (as elf_aux_info()). If is this acceptable, can you please suggest me best/suitable header for this function?
Is (new) auxv.h still OK?

This approach result to slightly bigger patches for ports (that getauxval), but it's still acceptable I think.

auxv.h is fine. Exporting elf_aux_info as weak symbol is also fine. Make sure that the interposable symbol is not used by libc or libthr.

[mmel]

Drop getauxval(), make _elf_aux_info() public.

[kib]

Perhaps split addition of AT_HWCAP2 and libc export commits.

@jhb planned to unify AT_XXX vector numbers across all arches, FYI.

sys/sys/auxv.h

35 ↗

(On Diff #34111)

?

[mmel]

Split out libc changes