This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] off_t: fix register pair calculation for 64-bit case
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Yury Norov <ynorov at caviumnetworks dot com>
- Cc: Arnd Bergmann <arnd at arndb dot de>, libc-alpha at sourceware dot org, "H.J. Lu" <hjl dot tools at gmail dot com>, Mike Frysinger <vapier at gentoo dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, Chris Metcalf <cmetcalf at tilera dot com>, Andrew Pinski <pinskia at gmail dot com>, cmetcalf at mellanox dot com
- Date: Tue, 28 Jun 2016 09:21:38 -0300
- Subject: Re: [PATCH] off_t: fix register pair calculation for 64-bit case
- Authentication-results: sourceware.org; auth=none
- References: <1466770980-18933-1-git-send-email-ynorov at caviumnetworks dot com> <28859060 dot mEqHA7rLP0 at wuerfel> <57711807 dot 1080002 at linaro dot org> <9748167 dot VNbN8ZdOaJ at wuerfel> <5771B019 dot 9010006 at linaro dot org> <20160628034402 dot GA15714 at yury-N73SV>
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.