Thread (73 messages) 73 messages, 9 authors, 2016-06-27

[PATCH v6 00/21] ILP32 for ARM64

From: Szabolcs Nagy <hidden>
Date: 2016-06-03 11:03:09
Also in: linux-arch, linux-s390, lkml

On 02/06/16 20:03, Yury Norov wrote:
On Tue, May 24, 2016 at 03:04:29AM +0300, Yury Norov wrote:
quoted
ILP32 glibc branch is available here:
https://github.com/norov/glibc/tree/ilp32-2.23
So for AARCH64/ILP32 we turn next types to 64-bit in glibc:
#define __INO_T_TYPE            __UQUAD_TYPE
#define __OFF_T_TYPE            __SQUAD_TYPE
#define __BLKCNT_T_TYPE         __SQUAD_TYPE
#define __FSBLKCNT_T_TYPE       __UQUAD_TYPE
#define __FSFILCNT_T_TYPE       __UQUAD_TYPE

And define:
# define __INO_T_MATCHES_INO64_T                1
# define __OFF_T_MATCHES_OFF64_T                1
# define __BLKCNT_T_MATCHES_BLKCNT64_T          1
# define __FSBLKCNT_T_MATCHES_FSBLKCNT64_T      1
# define __FSFILCNT_T_MATCHES_FSFILCNT_T        1

If so, stat and statfs  structures for ilp32 are turning the same as
for lp64. And so we'd handle related syscalls with native lp64
handlers (wrapped, to zero top halves) in kernel. 

And we don't need stat64 for ilp32.

Did I miss something? Is everything correct?

OFF_T is turned to 64-bit quite smoothly, others make applications
crash with segfault. Now I'm in deep debugging.
based on previous discussions, non-trivial glibc changes may
be needed to make 64bit fs apis the default on a 32bit abi.
http://sourceware.org/ml/libc-alpha/2016-05/msg00337.html
http://sourceware.org/ml/libc-alpha/2016-05/msg00356.html

but i guess if you consistently fix the 32bit assumptions
then it should work.
https://github.com/norov/glibc/commits/ilp32-dev
https://github.com/norov/linux/commits/ilp32

Yury.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help