https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107606
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2022-11-10
--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Florian Weimer from comment #2)
> (In reply to Segher Boessenkool from comment #1)
> > Or what else is the intention? Do you have an example of something that was
> > hard to debug, maybe?
>
> The prctl(2) manual page documents the prctl function as:
>
> int prctl(int option, unsigned long arg2, unsigned long arg3,
> unsigned long arg4, unsigned long arg5);
And it also says you have to include <sys/prctl.h> to use this, and that
header has a correct declaration. Could be worse ;-)
> But if you use this prototype to call prctl
You are never supposed to do that, you always should use the header file.
But people cut corners (which then ends up as being way more wasted work) :-(
> The prototype in <sys/prctl.h> matches this definition. We use to have an
> assembler implementation that did not clobber the caller stack even if
> called as a non-variadic function. But that got replaced in glibc 2.32,
> breaking some programs. We had similar portability issues with open/openat.
Ah, thanks for the background!
> Technically these things are all undefined, and the glibc headers and
> implementations are consistent.
And there is no standard that describe prctl(), which would be the last thing
justifying declaring it manually (like abort() is often declared manually
for example. Bad practice really, but not wrong).
> Users can even declare their own matching
> (variadic) prototypes, as required by POSIX for such functions. On the other
> hand, the prctl prototype is misdocumented, so it's easy to get that wrong,
> and the variadic nature of open/openat is not that widely realized, either.
That is misdocumented as well, yes.
> Basically this is an avoidable portability trap for powerpc64le-linux-gnu,
> and maybe we can make life for programmers a bit easier.
Many PowerPC ABIs, not just 64-bit even -- and probably many other archs
will have the same problem even. But it is more tractable to detect this
for rs6000 only, yup.
Confirmed.
