This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Patch 2 of 2 for ILP32 aarch64
On Tue, Feb 28, 2017 at 6:46 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 02/27/2017 05:48 PM, Arnd Bergmann wrote:
>>
>> On Mon, Feb 27, 2017 at 5:23 PM, Florian Weimer <fweimer@redhat.com>
>> wrote:
>>>
>>> On 02/22/2017 05:30 PM, Steve Ellcey wrote:
>>>>
>>>>
>>>> +#define __TIME_T_TYPE __SLONGWORD_TYPE
>>>
>>>
>>>
>>> Does this mean time_t remains 32 bits? Is this really a sane choice at
>>> this
>>> point for a new architecture?
>>
>>
>> Absolutely. We had a long discussion about this for the kernel port, and
>> the
>> conclusion is that we really need all types to be defined consistently
>> across
>> all architectures. If basic types like this were to differ between arm32
>> and
>> arm64/ilp32, then we could not support both ABIs from a single kernel
>> binary, as we can only have one set of compat syscall/ioctl ABI emulations
>> at build time, and this is not likely to change anytime soon (x86 tried to
>> do x32 and i386 emulation concurrently, but that support will probably
>> never
>> cover all device drivers).
>
>
> So—some people are under the impression that aarch64 ILP32 doesn't need
> compat syscalls at all. Are they wrong?
Yes, that wouldn't work at all, since many ABIs are defined in terms
of 'long' integer or pointer types. Even in x32, a number of important
syscalls use the compat handling while some others use the native
interfaces.
For arm64, we experimented with that as well, but now the user space
interface is almost exactly what we have for any other ILP32 architecture
with an ILP32 kernel. This means we can just use a subset of the
entry points we have for arm32, and don't have to worry about
interfaces that differ between the two 32-bit compat ABIs we support.
> In any case, I understand that 32-bit time_t makes things easier for the
> kernel, but from a userspace perspective, it means that ILP32 is more or
> less dead on arrival as far as potential long-term support in (enterprise)
> distros goes. Supporting new 32-bit architectures is a bit of a stretch at
> this point already, and the prospect of a hard ABI transition around ten
> years into the architecture/ABI lifetime isn't very compelling at all.
I'd hope that we can fully support 64-bit time_t on all 32-bit architectures
within the next year or two. As there are no legacy binaries for aarch64-ilp32
yet, we can probably expect people to do a rebuild of their software
if they care about long-term support.
> I really don't know what your expectations are. If aarch64 ILP32 is just a
> toy, then I don't see a problem; the community cost for dragging it along do
> not seem that high. But if there is a genuine expectation that it's going
> to be productized in some way, we might need something better.
The main use case of aarch64-ilp32 is transitional: you have existing
source that that is not 64-bit safe on some architecture other than aarch64
(powerpc, mips, arm32, ...) and want to bring it over to arm64 SoCs.
The first step is obviously to build it for aarch32, but not all arm64
implementations support that, so building as aarch64-ilp32 gets you
most of the way.
>From the kernel perspective, this is an important enough use case to
add support, but not important enough to take the maintenance burden
of doing something completely incompatible with every other ABI
just to have a random feature slightly earlier that everyone else.
Arnd