This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [BZ #19371] Properly handle x32 syscall



On 16-12-2015 15:01, H.J. Lu wrote:
> On Wed, Dec 16, 2015 at 8:58 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Wed, Dec 16, 2015 at 8:54 AM, Adhemerval Zanella
>> <adhemerval.zanella@linaro.org> wrote:
>>>
>>>
>>> On 16-12-2015 14:52, H.J. Lu wrote:
>>>> On Wed, Dec 16, 2015 at 8:48 AM, Dmitry V. Levin <ldv@altlinux.org> wrote:
>>>>> On Wed, Dec 16, 2015 at 07:01:39AM -0800, H.J. Lu wrote:
>>>>>> X32 syscall() may return 64-bit integer as lseek, time and times.  Its
>>>>>> return type should be __syscall_slong_t instead of long int.  We need
>>>>>> to properly return 64-bit error value.
>>>>> [...]
>>>>>> +#include <sysdep.h>
>>>>>> +
>>>>>> +/* Return -1LL in a full 64 bits.  */
>>>>>> +#undef SYSCALL_ERROR_HANDLER
>>>>>> +#define SYSCALL_ERROR_HANDLER        \
>>>>>> +0:                           \
>>>>>> +     SYSCALL_SET_ERRNO;      \
>>>>>> +     orq $-1, %rax;          \
>>>>>> +     ret;
>>>>>> +
>>>>>> +/* Always use our own error handler.  */
>>>>>> +#undef SYSCALL_ERROR_LABEL
>>>>>> +#define SYSCALL_ERROR_LABEL 0f
>>>>>> +
>>>>>> +#include <sysdeps/unix/sysv/linux/x86_64/syscall.S>
>>>>>
>>>>> While this looks technically OK, I don't understand why RAX_LP is used
>>>>> at all in default SYSCALL_ERROR_HANDLER in place for rax.  Everything
>>>>> would be simpler if glibc finally admitted that return code of any
>>>>> x32 linux syscall is stored in %rax and not in %eax.
>>>>
>>>> Only 3 system calls return 64-bit value.  %eax is one-byte shorter.
>>>>
>>>
>>> I still fail the see the performance gains over the re-engineering and
>>> code duplication required to avoid make the syscall return 64-bit values.
>>
>> What code duplication?
>>
> 
> The whole point of x32 is it is ILP32.  Some system calls return
> 64-bit is just an exception.
> 

And my point is to avoid the creation of multiple implementation of
same syscall, it only adds maintenance burden and complication on
GLIBC code (for instance the pread/pwrite case).

For this specific case if x32 SYSCALL_XXX macros retuned 64-bit values
there would be no need for another syscall.S implementation. Same for
the time.c patch.

And again I see no compelling performance reason to add such complexity. 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]