Message ID | 1488395968-14313-1-git-send-email-ynorov@caviumnetworks.com |
---|---|
Headers | show |
Series | ILP32 for ARM64 | expand |
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/cpufeature.c | 8 +- > arch/arm64/kernel/cpuinfo.c | 20 +-- > arch/arm64/kernel/entry.S | 34 +++++- > arch/arm64/kernel/entry32.S | 80 ------------ > arch/arm64/kernel/entry32_common.S | 107 ++++++++++++++++ > arch/arm64/kernel/entry_ilp32.S | 22 ++++ > arch/arm64/kernel/head.S | 2 +- > arch/arm64/kernel/hw_breakpoint.c | 8 +- > arch/arm64/kernel/perf_regs.c | 2 +- > arch/arm64/kernel/process.c | 7 +- > arch/arm64/kernel/ptrace.c | 80 ++++++++++-- > arch/arm64/kernel/signal.c | 102 ++++++++++------ > arch/arm64/kernel/signal32.c | 107 ---------------- > arch/arm64/kernel/signal32_common.c | 135 ++++++++++++++++++++ > arch/arm64/kernel/signal_ilp32.c | 170 ++++++++++++++++++++++++++ > arch/arm64/kernel/sys_ilp32.c | 100 +++++++++++++++ > arch/arm64/kernel/traps.c | 5 +- > arch/arm64/kernel/vdso-ilp32/.gitignore | 2 + > arch/arm64/kernel/vdso-ilp32/Makefile | 74 +++++++++++ > arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S | 33 +++++ > arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S | 95 ++++++++++++++ > arch/arm64/kernel/vdso.c | 69 +++++++++-- > arch/arm64/kernel/vdso/gettimeofday.S | 20 ++- > arch/arm64/kernel/vdso/vdso.S | 6 +- > arch/blackfin/Kconfig | 1 + > arch/c6x/include/uapi/asm/unistd.h | 1 + > arch/cris/Kconfig | 1 + > arch/frv/Kconfig | 1 + > arch/h8300/Kconfig | 1 + > arch/h8300/include/uapi/asm/unistd.h | 1 + > arch/hexagon/Kconfig | 1 + > arch/hexagon/include/uapi/asm/unistd.h | 1 + > arch/m32r/Kconfig | 1 + > arch/m68k/Kconfig | 1 + > arch/metag/Kconfig | 1 + > arch/metag/include/uapi/asm/unistd.h | 1 + > arch/microblaze/Kconfig | 1 + > arch/mips/Kconfig | 1 + > arch/mn10300/Kconfig | 1 + > arch/nios2/Kconfig | 1 + > arch/nios2/include/uapi/asm/unistd.h | 1 + > arch/openrisc/Kconfig | 1 + > arch/openrisc/include/uapi/asm/unistd.h | 1 + > arch/parisc/Kconfig | 1 + > arch/powerpc/Kconfig | 1 + > arch/score/Kconfig | 1 + > arch/score/include/uapi/asm/unistd.h | 1 + > arch/sh/Kconfig | 1 + > arch/sparc/Kconfig | 1 + > arch/tile/Kconfig | 1 + > arch/tile/include/uapi/asm/unistd.h | 1 + > arch/tile/kernel/compat.c | 3 + > arch/unicore32/Kconfig | 1 + > arch/unicore32/include/uapi/asm/unistd.h | 1 + > arch/x86/Kconfig | 1 + > arch/x86/um/Kconfig | 1 + > arch/xtensa/Kconfig | 1 + > drivers/clocksource/arm_arch_timer.c | 2 +- > include/linux/fcntl.h | 2 +- > include/linux/thread_bits.h | 63 ++++++++++ > include/linux/thread_info.h | 54 +------- > include/uapi/asm-generic/unistd.h | 10 +- > 93 files changed, 1586 insertions(+), 408 deletions(-) > create mode 100644 Documentation/arm64/ilp32.txt > create mode 100644 arch/arm64/include/asm/is_compat.h > create mode 100644 arch/arm64/include/asm/signal32_common.h > create mode 100644 arch/arm64/include/asm/signal_common.h > create mode 100644 arch/arm64/include/asm/signal_ilp32.h > create mode 100644 arch/arm64/kernel/binfmt_elf32.c > create mode 100644 arch/arm64/kernel/binfmt_ilp32.c > create mode 100644 arch/arm64/kernel/entry32_common.S > create mode 100644 arch/arm64/kernel/entry_ilp32.S > create mode 100644 arch/arm64/kernel/signal32_common.c > create mode 100644 arch/arm64/kernel/signal_ilp32.c > create mode 100644 arch/arm64/kernel/sys_ilp32.c > create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore > create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile > create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S > create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S > create mode 100644 include/linux/thread_bits.h > > -- > 2.7.4
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
On Apr 11 2017, Catalin Marinas <catalin.marinas@arm.com> 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, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
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
> 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
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.)
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