https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mkuvyrkov at gcc dot gnu.org
--- Comment #48 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> ---
Discussing this issue with Arnd Bergmann (kernel developer) and Christophe
Lyon, here is the analysis and how, I think, we should fix it:
The /manifesting/ issue is that definitions of __kernel_old_uid_t and
__kernel_old_gid_t have changed in AArch64 kernel headers several months ago.
This was a correct bug fix on kernel's part.
For various reason libsanitizer uses its own definitions of corresponding data
types (instead of including kernel headers), which, still, should match the
kernel definitions.
The /underlying/ issue is that libsanitizer is trying to handle compat syscalls
that should never occur in userspace. Specifically, at least __NR_getresuid16
and __NR_setresuid16 will never occur in native AArch64 code and are present in
the kernel for benefit of AArch32 applications running on AArch64 systems.
More generally, all references to __NR_<xxx>uid16 and __NR_<xxx>gid16 syscalls
should be surrounded with
#ifdef __NR_<xxx>uid32
// References to __NR_<xxx>uid16 are OK
#endif
... and similar for __NR_<xxx>gid16 syscalls.
Quoting Arnd:
When __NR_<xxx>uid32 is present, then __NR_<xxx>uid refers to the uid16
version.
If __NR_<xxx>uid32 does not exist, this means that __NR_<xxx>uid refers to the
uid32 version.
In summary, this problem affects several targets, of which AArch64 is one. I
believe the fix is confined to
lib/sanitizer_common/sanitizer_common_syscalls.inc and is a fairly mechanical
one.
The last bit of business left is for someone to implement the above fix, test
it, and commit to both LLVM and GCC.
