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] off_t: fix register pair calculation for 64-bit case



On 28/06/2016 00:44, Yury Norov wrote:
> On Mon, Jun 27, 2016 at 08:00:41PM -0300, Adhemerval Zanella wrote:
>>
>>
>> On 27/06/2016 18:01, Arnd Bergmann wrote:
>>> On Monday, June 27, 2016 9:11:51 AM CEST Adhemerval Zanella wrote:
>>>>>
>>>>>> The whole idea of ILP32 patchset is to be a counterpart for kernel code
>>>>>> that clears top halves of registers unconditionally at now. It means we
>>>>>> cannot pass any 64-bit value in a single register, and that's what
>>>>>> the code under sysdeps/unix/sysv/linux/wordsize-64 does. So I don't
>>>>>> understand how we can use it.
>>>>>
>>>>> The code in sysdeps/unix/sysv/linux/wordsize-64 seems to be made for
>>>>> the 64-bit syscall API, which is not appropriate here as the kernel
>>>>> port uses the 32-bit syscall API, now basically unchanged.
>>>>>
>>>>> This is the same as tile64/ilp32 does, but different from x86-64/ilp32
>>>>> (x32).
>>>>
>>>> I intend to send a patch upstream to consolidate all the fallocate
>>>> implementation to help this very issue.  The idea is to use the same
>>>> pread consolidate idea:
>>>>
>>>>   1. Each architecture/ABI defines if its a ILP32 (__ASSUME_WORDSIZE64_ILP32)
>>>>      and if off64_t differs in size of off_t (__ASSUME_OFF_DIFF_OFF64).
>>>>      Currently, x32 defines __ASSUME_WORDSIZE64_ILP32 and only MIPS64-n32
>>>>      defines both __ASSUME_WORDSIZE64_ILP32 and __ASSUME_OFF_DIFF_OFF64.
>>>>
>>>>   2. For the default function implementation (without the 64 suffix)
>>>>      the symbol will be built if is 32-bits (__WORDSIZE==64) or
>>>>      if off_t differs in size from off64_t (__ASSUME_OFF_DIFF_OFF64).
>>>>
>>>>      It means that for architecture that only pass 64-bit off_t this
>>>>      symbol won't be build.
>>>>
>>>>   3. The 64 variant of the function implementation (with the 64 suffix)
>>>>      will be always build and a weak alias for the non-suffix variant
>>>>      will be created if __WORDSIZE == 64 and if size of off64_t differs
>>>>      from off_t.
>>>>
>>>>      It means that for architecture that only pass 64-bits off_t 
>>>>      function will be an alias to function64.
>>>>
>>>> I think with this patch there is no need to more arch-specific implementation.
>>>
>>> Doesn't that assume that the kernel interface uses 64-bit registers
>>> to pass off_t?  Yury's patch was specifically for the case where
>>> you use two 32-bit registers (or two lower halves of 64-bit registers
>>> in case of aarch64) but still want 64-bit off_t by default,
>>> i.e. (!defined(__ASSUME_WORDSIZE64_ILP32) && !defined(__ASSUME_OFF_DIFF_OFF64)).
>>>
>>> 	Arnd
>>>
>>
>> So if I understood correctly AArch64/ILP32 will another way to handle 
>> off_t/off64_t, which indeed the original patch make sense.
> 
> Yes. You understood correctly. This is how RISC-V works, and this is
> default behavior for all new 32-bit ABIs, both native and ILP32.
> 
> Is my understanding correct that for AARCH64/ILP32, in glibc terms
> we have solid understanding that __ASSUME_OFF_DIFF_OFF64 is disabled;
> and__ASSUME_WORDSIZE64_ILP32 depends on kernel wrappers, and under
> discussion.
> 
> Could you (someone) explain me the difference between
> __ASSUME_OFF_DIFF_OFF64 and __OFF_T_MATCHES_OFF64_T?
> At first glance they are mutual exclusive, and so we
> can drop one of them.

I see they are essentially the same and I added __ASSUME_OFF_DIFF_OFF64
on my pread consolidation by two main reasons:

  1. It is defined only internally on GLIBC
  2. By default on 32 bits it assumes off_t differs from off64_t and
     for 64 bits it is the contrary.  

On current GLIBC supported architectures it requires only MIPS64-n32 to
define it.  However since current kernel new port approach is make
size of off_t the same as off64_t I see that all new ports will require
to define it.

I do not have a strong opinion which is the better approach, the only
nit is I think it should not be on an installed header.


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