Re: [PATCH] Linux: Support non-variadic calls to prctl (bug 29770)

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 09/04/2023 16:46, Florian Weimer wrote:
> * Szabolcs Nagy:
> >> I don't think that's true for our current ABIs.  They support
> >> unprototyped calls, and by extension this also means that calls through
> >> a variadic prototype to a prototyped non-variadic function must work as
> >> well.  There are other ABIs which do not work this way, but glibc hasn't
> >> been ported to them (and it's unclear how useful they would be for
> >> GNU/Linux).
> >
> > this is not true in general.
> >
> > unprototyped call to variadic functions is not valid in c.
> 
> It is valid C before C99.

as far as i can tell iso c never allowed unprototyped call
to variadic functions.

(looking at sections "3.3.2.2 Function calls" and
"3.7.1 Function definitions" in c89.)

> GCC still accepts unprotyped calls with a warning in all C language
> modes, which is why I think we need to keep supporting it.

for me gcc accepts

void f(int, double);
void f();

but errors on

void f(int, ...);
void f();

as it should.

> > so unprototyped call abi does not have to match both the
> > variadic and non-variadic call abi. (only non-variadic calls
> > with arg types that promote to themselves need to work.)
> 
> It's true that the ABI does not have to match exactly.  We already have
> several ABIs where non-variadic calls to functions implemented as
> variadic functions fail.  to my knowledge, we do not have something in
> the other direction (and we really can't, for pre-C99 support).

i gave an example below if we allow floating-point arguments.

> > e.g. on arm variadic functions always take float args following the
> > soft float abi, but an unprototyped call with double args uses the
> > hard float abi on armhf (int vs float regs).
> 
> How do you maintain C89 compatibility with such an ABI?  I assume the
> difference is only in the non-variadic part.  For the variadic part,
> float needs to be promoted to double.

an f(1,1.0) call is abi compat between

double f(int, double);
double f();

declarations (double is passed/returned in fp regs), but

double f(int, ...);

is different (double is passed/returned in a pair of int regs).

this is valid c89 implementation.

> > i guess the prctl case works on existing abis now, but i think
> > future abis might want different variadic call abi (morello is an
> > example, though that's an experimental target).
> 
> The ABIs are already different today on powerpc64le today, even for
> prctl.  Variadic functions on powerpc64le assume additional setup by the
> caller, which does not happen with a non-variadic call.
> 
> The man-pages project used to document prctl as a non-variadic function.

the man-pages project is confused when it is documenting
syscalls, sometimes documenting the linux abi other times
the libc api or not following c rules at all (see e.g.
open or futex man pages).

what matters is how the function was declared in glibc
headers.. glibc could make the declaration non-variadic
which would solve a lot of issues, but i guess a new
symbol should be used for that then.

> > prctl is nasty because the arguments are often passed with the
> > wrong type (e.g. int arguments instead of unsigned long) and
> > with variadic prototype this can pass wrong value (e.g. non-zero
> > top bits on 64bit targets) down to the kernel. unfortunately
> > whatever glibc does internally won't solve this issue: the public
> > API would need to change.
> 
> The C wrapper I'm fixing tries to solve this for the ILP32 with 64-bit
> syscall registers case.  It's just that the original fix exposes another
> bug.

not sure how you can solve this with a wrapper.
unless it is libc header magic.