Re: [PATCH v2] Add public function syscall_no_errno

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 12/02/24 14:25, Zack Weinberg wrote:
> On Mon, Feb 12, 2024, at 11:16 AM, Askar Safin wrote:
>> ---- On Mon, 12 Feb 2024 18:44:31 +0400  Rich Felker  wrote ---
>>  > Yes, there are a very small number of such syscalls -- getuid and
>>  > getgid are the only relevant ones AFAICT -- but the author of this
>>  > proposal is missing the point
>>
>> Okay, I declare defeat
> 
> I have a question for you: Do glibc's existing getuid() and getgid()
> functions correctly handle IDs in the [-4095, -1] range (perhaps better
> described as the [4294963201, 4294967295] range) ?  It appears to me
> from binary code inspection that they do -- here's the assembly dump of
> getuid() on x86-64:
> 
> (gdb) disas getuid
> Dump of assembler code for function __GI_getuid:
>    0x00000000000cf940 <+0>:	mov    $0x66,%eax
>    0x00000000000cf945 <+5>:	syscall
>    0x00000000000cf947 <+7>:	ret
> End of assembler dump.

Afaiu this is not an issue for x86_64, or any other 64-bit architecture,
because uid_t/gid_t are exported as an uint32_t (__UID_T_TYPE/__U32_TYPE),
and the invalid return valid are in the range of [-4096UL,-1UL].

> 
> But I am not having any luck figuring out what bit of glibc's *source*
> code tells the syscall stub generator not to emit the code to check for
> error returns for these syscalls, so it's plausible to me that there is
> a bug in here somewhere, possibly only on lesser-used architectures.  If
> you know of a case where we get this wrong, please tell us about it so
> we can fix it.
> 
> zw