Re: [PATCH] nolibc/stdlib: Improve `getauxval(3)` implementation

[Willy Tarreau]

On Wed, Jan 17, 2024 at 01:52:06AM +0700, Ammar Faizi wrote:
> On Tue, Jan 16, 2024 at 01:11:47PM -0500, Charles Mirabile wrote:
> > At least on x86-64, the ABI only specifies that one more long will be
> > present with value 0 (type AT_NULL) after the pairs of auxv entries.
> > Whether or not it has a corresponding value is unspecified. This value is
> > present on linux, but there is no reason to check it as simply seeing an
> > auxv entry whose type value is AT_NULL should be enough.
> 
> Yeah, I agree with that. I just read the ABI and confirmed that the
> 'a_un' member is ignored when the type is `AT_NULL`. Let's stop relying
> on an unspecified value.
> 
> For others who want to check, see page 37 and 38:
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/wikis/uploads/221b09355dd540efcbe61b783b6c0ece/x86-64-psABI-2023-09-26.pdf
> 
> > This is a matter of taste, but I think processing the data in a structured
> > way by coercing it into an array of type value pairs, using multiple
> > return style, and a for loop with a clear exit condition is more readable
> > than the existing infinite loop with multiple exit points and a return
> > value variable.
> 
> Ok. It's more readable using your way. One thing that bothers me a bit
> is type of 'a_type'. On page 37, the ABI defines the auxv type-val pair
> as:
> 
>   typedef struct
>   {
>     int a_type;
>     union {
>       long a_val;
>       void *a_ptr;
>       void (*a_fnc)();
>     } a_un;
>   } auxv_t;
> 
> Assuming the arch is x86-64 Linux. Note that 'a_type' is an 'int' which
> is 4 bytes in size, but we use 'unsigned long' instead of 'int' to
> represent it. However, since 'a_un' needs to be 8 bytes aligned, the
> compiler will put a 4 bytes padding between 'a_type' and 'a_un', so it
> ends up just fine (on x86-64).
> 
> What do you think about other architectures? Will it potentially be
> misinterpreted?

Indeed, it would fail on a 64-bit big endian architecture. Let's
just declare the local variable the same way as it is in the spec,
it will be much cleaner and more reliable.

Thanks,
Willy