This is the mail archive of the
mailing list for the glibc project.
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64
- From: Arnd Bergmann <arnd at arndb dot de>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Yury Norov <ynorov at caviumnetworks dot com>, catalin dot marinas at arm dot com, linux-arm-kernel at lists dot infradead dot org, linux-kernel at vger dot kernel dot org, nd at arm dot com, linux-arch at vger dot kernel dot org, linux-s390 at vger dot kernel dot org, pinskia at gmail dot com, Prasun dot Kapoor at caviumnetworks dot com, schwab at suse dot de, broonie at kernel dot org, linux-doc at vger dot kernel dot org, heiko dot carstens at de dot ibm dot com, agraf at suse dot de, klimov dot linux at gmail dot com, bamvor dot zhangjian at huawei dot com, schwidefsky at de dot ibm dot com, Nathan_Lynch at mentor dot com, joseph at codesourcery dot com, christoph dot muellner at theobroma-systems dot com, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 17 May 2016 17:37:55 +0200
- Subject: Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64
- Authentication-results: sourceware.org; auth=none
- References: <1459894127-17698-1-git-send-email-ynorov at caviumnetworks dot com> <573B0A4D dot 4090704 at arm dot com>
On Tuesday 17 May 2016 13:10:53 Szabolcs Nagy wrote:
> On 05/04/16 23:08, Yury Norov wrote:
> > This version is rebased on kernel v4.6-rc2, and has fixes in signal subsystem.
> > It works with updated glibc  (though very draft), and tested with LTP.
> > It was tested on QEMU and ThunderX machines. No major difference found.
> > This is RFC because ILP32 is not tested in big-endian mode.
> > v3: https://lkml.org/lkml/2014/9/3/704
> > v4: https://lkml.org/lkml/2015/4/13/691
> > v5: https://lkml.org/lkml/2015/9/29/911
> > v6:
> > - time_t, __kenel_off_t and other types turned to be 32-bit
> > for compatibility reasons (after v5 discussion);
> i added libc-alpha to cc, the thread is at
> or http://thread.gmane.org/gmane.linux.kernel.cross-arch/31449
> the kernel position seems to be that the aarch64 ilp32 syscall abi
> will follow regular 32bit abis (apart from signal context and ptrace
> related things and syscalls will take 64bit arguments).
> i think the reasoning is that this allows legacy (non-64bit-safe)
> software to use this abi on aarch64 without trouble.
> i think this design should be ok for glibc.
> there are some interop issues between processes following different abis
> (e.g. shared mutexes, abi specific file formats, lib paths,..) which apply,
> but i assume it is no different from existing 32bit vs 64bit issues.
> the 32bit time_t and off_t are ugly and i wonder if 32bit __kernel_off_t
> is really necessary. (i don't see where that is changed: it is supposed
> to be __kernel_long_t which is 64bit).
__kernel_off_t and __kernel_ino_t are always 'long' and 'unsigned long'
for historic reasons, but they are not used at all on modern architectures.
We could add a few lines with #ifdef to the kernel headers to hide the
definition on architectures that don't use them, but that seems pointless
given that glibc just defines its own version.
For time_t, I'm working on the same thing in the long run: there will
be a 64 bit __kernel_time64_t that is always used on all architectures,
and a __kernel_time_t that is provided for backwards compatibility
with old libc on architectures that started out having it.
__kernel_long_t should not be 64 bit on 32-bit architectures, it is the
size of the 'long' type in the ABI and defining it as 'long long' on
x32 keeps causing problems that we should not add on new architectures.
> i think even legacy software should be able to deal with 64bit off_t,
> so we could avoid having two sets of filesystem apis or is 64bit-only
> off_t more work to do in linux/glibc?
All architectures that got merged in the last 10 years only support
64-bit __kernel_loff_t in the kernel but not __kernel_off_t, this
includes arc, c6x, h8300, hexagon, metag, nios2, openrisc, tile and
unicore32. However, glibc implements 32-bit off_t on top of the
64-bit syscall interfaces. I believe this was done to keep the code
looking more like the older 32-bit architectures.
I think it has become easier to override now and we just need to
update sysdeps/unix/sysv/linux/generic/bits/typesizes.h to set
#define __INO64_T_TYPE __UQUAD_TYPE
#define __OFF64_T_TYPE __UQUAD_TYPE
#define __OFF_T_MATCHES_OFF64_T 1
#define __INO_T_MATCHES_INO64_T 1
for new architectures (obviously not the ones that already use the
32-bit types). I haven't tries this, so there may be other things
that are required.