Bug 113728 - libasan uses incorrect prctl prototype
Summary: libasan uses incorrect prctl prototype
Status: RESOLVED MOVED
Alias: None
Product: gcc
Classification: Unclassified
Component: sanitizer (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-02 21:27 UTC by Florian Weimer
Modified: 2024-02-27 06:03 UTC (History)
7 users (show)

See Also:
Host:
Target: powerpc64le-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Weimer 2024-02-02 21:27:08 UTC 
The prctl function in glibc is variadic, but the internal prototype used by libasan has a fixed argument list.

This causes crashes on powerpc64le-linux-gnu with current glibc because the glibc implementation is variadic as well, it uses <stdarg.h>. Older glibc uses an assembler implementation which does not bother with variadic arguments. For variadic function calls, it's the caller's responsibility to set up the parameter save area, but that does not happen if function prototype is incorrect and non-variadic.

I'll try to get this worked around in glibc, but I couldn't get my ABI regression fix applied the first time I posted it. The libasan library isn't the first application impacted by the prctl ABI change.
Comment 1 Andrew Pinski 2024-02-02 21:28:51 UTC 
Can you file this upstream to LLVM too?
Comment 2 Florian Weimer 2024-02-17 12:16:55 UTC 
This has been worked around in glibc. Should we close this issue?
Comment 3 Peter Bergner 2024-02-27 03:53:22 UTC 
(In reply to Florian Weimer from comment #2)
> This has been worked around in glibc. Should we close this issue?

As the bug reporter and given glibc now has a workaround, I think you're fine to close this if you think there's nothing to be done in GCC.
Comment 4 Florian Weimer 2024-02-27 06:03:38 UTC 
Then let's close it. We'll get the fix from LLVM if it ever gets implemented.