Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit architectures?
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): CA+=Sn1=2OK+NiANuJP-u6CVo8_UH8miSwGQNsgih3r=ewSBUjw@mail.gmail.com
A message that is not in the archive (sent off-list or not yet received): BY2PR07MB23110A53F68F80960FCBD123935C0@BY2PR07MB2311.namprd07.prod.outlook.com
Quoted 22 lines · Andrew
You may also want to look into this thread. It just got started too.
-----Original Message-----
From: Andrew Pinski [mailto:[email protected]]
Sent: Monday, June 6, 2016 12:03 PM
To: Pinski, Andrew <[email protected]>
Subject: Fwd: [RFC] Forcing 64-bits__OFF_T_TYPEand__INO_T_TYPEfor new 32-bit architectures?---------- Forwarded message ----------
From: Manuel A. Fernandez Montecelo <[email protected]>
Date: Mon, Jun 6, 2016 at 11:51 AM
Subject: [RFC] Forcing 64-bits__OFF_T_TYPEand__INO_T_TYPEfor new 32-bit architectures?
To: [email protected]Hi,
When discussing how to implement these types for the RISC-V architecture (32, 64 and 128-bit flavours), it seems that there's a drive [1][2] to force new arches to use the 64-bit versions of these types (so they would be the same as
__OFF64_T_TYPEand__INO64_T_TYPE), even for 32-bit arches.
Quoted 6 lines
Does this look like a reasonable approach?
https://github.com/manuelafm/riscv-gnu-toolchain/commit/764f5ac958618c1ca8761845864164365282ffbd
(also attached)
Hi Manuel,
It seems, we are working on the same issue. AARCH64/ilp32 ABI is going to work the way you described below. I found next types to be turned to 64-bit
[https://www.mail-archive.com/[email protected]/msg1157969.html]:
Quoted 14 lines
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_TYPEAnd 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
Quoted 3 lines
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.
^^^ The main goal ^^^
Quoted 8 lines
And we don't need stat64 for ilp32.
Did I miss something? Is everything correct?
https://github.com/norov/glibc/commits/ilp32-dev
https://github.com/norov/linux/commits/ilp32
Under links below you can find my current progress on this work. Also notice how I redeclared struct timespec.
#ifdef timespec_needs_pads
# if __BYTE_ORDER == __LITTLE_ENDIAN
struct timespec
{
__time_t tv_sec; /* Seconds. */
int sec_pad;
__syscall_slong_t tv_nsec; /* Nanoseconds. */
int nsec_pad;
};
# else
struct timespec
{
int sec_pad;
__time_t tv_sec; /* Seconds. */
int nsec_pad;
__syscall_slong_t tv_nsec; /* Nanoseconds. */
};
# endif
#else
struct timespec
{
__time_t tv_sec; /* Seconds. */
__syscall_slong_t tv_nsec; /* Nanoseconds. */
};
#endif /* timespec_needs_pads */I'm little worry about correctness of this approach. But if you define the whole new RISC-V arch, I think, new timeskpec is OK there.
BTW, just curious, why RISK-V. I think it will work for CISC as well. And what '-V' means?
Yury.
Quoted 12 lines
[1] At least from people in the Linux kernel community.
[2] A further suggestion was that all new arches should default to have the same width for these types, 64 bits, and override
__OFF_T_TYPEand__INO_T_TYPEfor all the existing architectures where they are currently 32-bits. I don't know if this is desirable at this point.Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>