Re: [RFC2 nowrap: PATCH v7 00/18] ILP32 for ARM64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 17 Aug 2016, at 14:48, Yury Norov <ynorov@xxxxxxxxxxxxxxxxxx> wrote:
> 
> On Wed, Aug 17, 2016 at 02:28:50PM +0200, Alexander Graf wrote:
>> 
>>> On 17 Aug 2016, at 13:46, Yury Norov <ynorov@xxxxxxxxxxxxxxxxxx> wrote:
>>> 
>>> This series enables aarch64 with ilp32 mode, and as supporting work,
>>> introduces ARCH_32BIT_OFF_T configuration option that is enabled for
>>> existing 32-bit architectures but disabled for new arches (so 64-bit
>>> off_t is is used by new userspace).
>>> 
>>> This version is based on kernel v4.8-rc2.
>>> It works with glibc-2.23, and tested with LTP.
>>> 
>>> This is RFC because there is still no solid understanding what type of registers
>>> top-halves delousing we prefer. In this patchset, w0-w7 are cleared for each
>>> syscall in assembler entry. The alternative approach is in introducing compat
>>> wrappers which is little faster for natively routed syscalls (~2.6% for syscall
>>> with no payload) but much more complicated.
>> 
>> So you’re saying there are 2 options:
>> 
>>  1) easy to get right, slightly slower, same ABI to user space as 2
>>  2) harder to get right, minor performance benefit
> 
> No, ABI is little different. If 1) we pass off_t in a pair to syscalls,
> if 2) - in a single register. So if 1, we 'd take some wrappers from aarch32.
> See patch 12 here.

>From our experience with ILP32, I’d prefer to have off_t (and similar) in a single register
whenever possible (i.e. option #2).  It feels more natural to use the full 64bit registers 
whenever possible, as ILP32 on ARMv8 should really be understood as a 64bit ABI with 
a 32bit memory model.

Cheers,
Philipp.--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux