Re: [PATCH v7 resend 00/20] ILP32 for ARM64
On Tue, Apr 11, 2017 at 08:42:24PM +0200, Florian Weimer wrote:
> On 04/11/2017 08:36 PM, Yury Norov wrote:
> >>Also, the latest benchmarks I've seen were mostly for user space
> >>while I'm more concerned with the user-kernel interface
> >>(https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2).
> >
> >>On the glibc testing side, have the regressions been identified/fixed?
> >
> >I run LTP for testing the ABI and kernel, and there is no failures in
> >ltplite scenario. With glibc testsuite, there's only 3 failures
> >comparing to lp64. (Steve, fix me if something changed.) This is
> >slides on ilp32 from Linaro Connect, hope you'll find it useful.
> >
> >https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing
>
> The listed failures are:
>
> misc/tst-sync_file_range
> nptl/tst-stack4
> malloc/tst-mallocstate
>
> If necessary, I will fix malloc/tst-mallocstate once there's support for a
> new architecture in build-many-glibcs.py. The failure is
> architecture-independent, it's related to the lack of a compat symbol and
> the difficulty of checking for that at the Makefile or test level.
>
> nptl/tst-stack4 is also a generic failure, I think.
That would be great, thanks.
> misc/tst-sync_file_range is probably a real failure related to argument
> passing. I think this system call was problematic on other architectures,
> too.
At first glance, it's pretty trivial, both on glibc and kernel side:
GLIBC:
int
sync_file_range (int fd, __off64_t offset, __off64_t len, unsigned int flags)
{
#if defined (__NR_sync_file_range2)
return SYSCALL_CANCEL (sync_file_range2, fd, flags, SYSCALL_LL64 (offset),
SYSCALL_LL64 (len));
#elif defined (__NR_sync_file_range)
return SYSCALL_CANCEL (sync_file_range, fd,
__ALIGNMENT_ARG SYSCALL_LL64 (offset),
SYSCALL_LL64 (len), flags);
#endif
}
And kernel:
ENTRY(compat_sys_sync_file_range2_wrapper)
regs_to_64 x2, x2, x3
regs_to_64 x3, x4, x5
b sys_sync_file_range2
ENDPROC(compat_sys_sync_file_range2_wrapper)
Anyway, I'll check everything and report here.
Yury
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
On 04/11/2017 08:36 PM, Yury Norov wrote: Also, the latest benchmarks I've seen were mostly for user space while I'm more concerned with the user-kernel interface (https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2). On the glibc testing side, have the regressions been identified/fixed? I run LTP for testing the ABI and kernel, and there is no failures in ltplite scenario. With glibc testsuite, there's only 3 failures comparing to lp64. (Steve, fix me if something changed.) This is slides on ilp32 from Linaro Connect, hope you'll find it useful. https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing The listed failures are: misc/tst-sync_file_range nptl/tst-stack4 malloc/tst-mallocstate If necessary, I will fix malloc/tst-mallocstate once there's support for a new architecture in build-many-glibcs.py. The failure is architecture-independent, it's related to the lack of a compat symbol and the difficulty of checking for that at the Makefile or test level. nptl/tst-stack4 is also a generic failure, I think. misc/tst-sync_file_range is probably a real failure related to argument passing. I think this system call was problematic on other architectures, too. Thanks, Florian (Sorry for the wide Cc: list despite the glibc content.) -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
> Also, the latest benchmarks I've seen were mostly for user space > while I'm more concerned with the user-kernel interface > (https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2). > On the glibc testing side, have the regressions been identified/fixed? I run LTP for testing the ABI and kernel, and there is no failures in ltplite scenario. With glibc testsuite, there's only 3 failures comparing to lp64. (Steve, fix me if something changed.) This is slides on ilp32 from Linaro Connect, hope you'll find it useful. https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing Yury -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
On Tue, Apr 11, 2017 at 12:33:35PM +0100, Catalin Marinas wrote: > On Mon, Apr 10, 2017 at 11:47:40PM +0400, Yury Norov wrote: > > According to latest plans figured out on Linaro Connect, ILP32 should > > be taken in 4.12 merge window. > > Sorry, I wasn't present at Linaro Connect, so definitely not involved in > such decision. > > BTW, it would be nice to have Arnd's ack on patch 2 (32-bit ABI: > introduce ARCH_32BIT_OFF_T config option). He already acked it, but after some rebase I lost that line http://lists-archives.com/linux-kernel/28471253-32-bit-abi-introduce-arch_32bit_off_t-config-option.html Yury -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
On Apr 11 2017, Catalin Marinas wrote: > Is there an up to date pre-built toolchain and a filesystem for ILP32? https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32 should have everything you need. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
On Mon, Apr 10, 2017 at 11:47:40PM +0400, Yury Norov wrote: > According to latest plans figured out on Linaro Connect, ILP32 should > be taken in 4.12 merge window. Sorry, I wasn't present at Linaro Connect, so definitely not involved in such decision. BTW, it would be nice to have Arnd's ack on patch 2 (32-bit ABI: introduce ARCH_32BIT_OFF_T config option). > The window will be opened in less than a month, so I'd like to remind > it to you, and ask if you have any questions/requests related to > ILP32. Is it still realistic idea to take patches in 4.12? 4.12 is not realistic and I wouldn't commit to a specific kernel version. Given the intrusiveness, such patches should sit in -next for at least 3-4 weeks (i.e. merged in the arch tree around -rc3). Anyway, I don't think the plan has changed since last time I stated it: https://lkml.org/lkml/2016/12/5/333 I haven't got the chance to test these patches yet, run benchmarks (step 4). Also, the latest benchmarks I've seen were mostly for user space while I'm more concerned with the user-kernel interface (https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2). Is there an up to date pre-built toolchain and a filesystem for ILP32? On the glibc testing side, have the regressions been identified/fixed? -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
Hi Catalin,
According to latest plans figured out on Linaro Connect, ILP32 should
be taken in 4.12 merge window. The window will be opened in less than
a month, so I'd like to remind it to you, and ask if you have any
questions/requests related to ILP32. Is it still realistic idea to take
patches in 4.12?
This is the rebase of ILP32 on latest linux-next:
https://github.com/norov/linux/tree/ilp32-20170410
And glibc that I use for testing:
https://github.com/norov/glibc/commits/dev9
Yury
On Thu, Mar 02, 2017 at 12:49:08AM +0530, Yury Norov wrote:
> This series enables aarch64 with ilp32 mode.
>
> As supporting work, it 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). Also it
> deprecates getrlimit and setrlimit syscalls prior to prlimit64.
>
> This version is based on linux-next from 2017-03-01. It works with
> glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
> CPUSpec.
>
> Patches 1, 2, 3 and 8 are general, and may be applied separately.
>
> This is the rebase of v7 - no major changes has been made.
>
> Kernel and GLIBC trees:
> https://github.com/norov/linux/tree/ilp32-20170301
> https://github.com/norov/glibc/tree/dev9
>
> (GLIBC patches are managed by Steve Ellcey, so my tree is only for
> reference.)
>
> Changes:
> 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: https://lkml.org/lkml/2016/5/23/661
> v7: RFC nowrap: https://lkml.org/lkml/2016/6/17/990
> v7: RFC2 nowrap: https://lkml.org/lkml/2016/8/17/245
> v7: RFC3 nowrap: https://lkml.org/lkml/2016/10/21/883
> v7: https://lkml.org/lkml/2017/1/9/213
> v7: Resend: fixed couple of typos, rebased on next-20170301
>
> Andrew Pinski (6):
> arm64: rename COMPAT to AARCH32_EL0 in Kconfig
> arm64: ensure the kernel is compiled for LP64
> arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
> arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
> it
> arm64: ilp32: introduce ilp32-specific handlers for sigframe and
> ucontext
> arm64:ilp32: add ARM64_ILP32 to Kconfig
>
> Philipp Tomsich (1):
> arm64:ilp32: add vdso-ilp32 and use for signal return
>
> Yury Norov (13):
> compat ABI: use non-compat openat and open_by_handle_at variants
> 32-bit ABI: introduce ARCH_32BIT_OFF_T config option
> asm-generic: Drop getrlimit and setrlimit syscalls from default list
> arm64: ilp32: add documentation on the ILP32 ABI for ARM64
> thread: move thread bits accessors to separated file
> arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
> arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
> arm64: introduce binfmt_elf32.c
> arm64: ilp32: introduce binfmt_ilp32.c
> arm64: ilp32: share aarch32 syscall handlers
> arm64: signal: share lp64 signal routines to ilp32
> arm64: signal32: move ilp32 and aarch32 common code to separated file
> arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
>
> Documentation/arm64/ilp32.txt | 45 +++
> arch/Kconfig | 4 +
> arch/arc/Kconfig | 1 +
> arch/arc/include/uapi/asm/unistd.h| 1 +
> arch/arm/Kconfig | 1 +
> arch/arm64/Kconfig| 19 ++-
> arch/arm64/Makefile | 5 +
> arch/arm64/include/asm/compat.h | 19 +--
> arch/arm64/include/asm/elf.h | 32 ++---
> arch/arm64/include/asm/fpsimd.h | 2 +-
> arch/arm64/include/asm/ftrace.h | 2 +-
> arch/arm64/include/asm/hwcap.h| 6 +-
> arch/arm64/include/asm/is_compat.h| 90 ++
> arch/arm64/include/asm/memory.h | 5 +-
> arch/arm64/include/asm/processor.h| 11 +-
> arch/arm64/include/asm/ptrace.h | 2 +-
> arch/arm64/include/asm/seccomp.h | 2 +-
> arch/arm64/include/asm/signal32.h | 9 +-
> arch/arm64/include/asm/signal32_common.h | 27
> arch/arm64/include/asm/signal_common.h| 33 +
> arch/arm64/include/asm/signal_ilp32.h | 38 ++
> arch/arm64/include/asm/syscall.h | 2 +-
> arch/arm64/include/asm/thread_info.h | 4 +-
> arch/arm64/include/asm/unistd.h | 8 +-
> arch/arm64/include/asm/vdso.h | 6 +
> arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
> arch/arm64/include/uapi/asm/unistd.h | 13 ++
> arch/arm64/kernel/Makefile| 18 ++-
> arch/arm64/kernel/asm-offsets.c | 9 +-
> arch/arm64/kernel/binfmt_elf32.c | 32 +
> arch/arm64/kernel/binfmt_ilp32.c | 85 +
> arch/arm64/kernel
