| Message ID | 56F6825B.7000906@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Saturday 26 March 2016 20:36:43 Zhangjian wrote: > Hi, Arnd > > On 2016/3/21 17:43, Arnd Bergmann wrote: > > On Monday 21 March 2016 10:07:49 Andreas Schwab wrote: > >> This patch may fix a few LTP tests. > >> > > > > Thanks for analyzing. > > > >> diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h > >> index 3631903..d1010db 100644 > >> --- a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h > >> +++ b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h > >> @@ -25,18 +25,29 @@ > >> #define __O_NOFOLLOW 0100000 > >> #define __O_DIRECT 0200000 > >> > >> -#define __O_LARGEFILE 0 > >> +#ifdef __ILP32__ > >> +# define __O_LARGEFILE 0400000 > >> +#else > >> +# define __O_LARGEFILE 0 > >> +#endif > >> > > > > I guess this means I screwed up when I said I'd merged the kernel patch > > that Yury did to fix it, sorry about that. > > > > We need the patch to make all new architecture in the kernel default to > > O_LARGEFILE, and not do this in user space. I'd suggest now to keep the > > patches as part of the ILP32 series after all, to make sure they are > > merged at the point when they are needed. > > I am a little bit confuse about off_t. In "[PATCH 08/33] 32-bit > ABI: introduce ARCH_32BIT_OFF_T config option", it mentioned that all > the new 32bit architecture should use 64bit off_t. Ah, so it is part of the series. I had not checked that here. > Should we define off_t in aarch64(for both ilp32 and lp64) in > typesize.h as following? > > diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > index 7073493..13b77c5 100644 > --- a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > +++ b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > @@ -33,7 +33,7 @@ > #define __INO64_T_TYPE __UQUAD_TYPE > #define __MODE_T_TYPE __U32_TYPE > #define __NLINK_T_TYPE __U32_TYPE > -#define __OFF_T_TYPE __SLONGWORD_TYPE > +#define __OFF_T_TYPE __SQUAD_TYPE > #define __OFF64_T_TYPE __SQUAD_TYPE > #define __PID_T_TYPE __S32_TYPE > #define __RLIM_T_TYPE __ULONGWORD_TYPE > > Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in > aarch64. And truncate and ftruncate is same as truncate64 and > ftruncate64. I don't know what the glibc developers prefer, but I think the result needs to be something like that: either __OFF_T_TYPE is defined as you write above as a 64-bit type, or the user-visible off_t typedef unconditionally uses __OFF64_T_TYPE rather than __OFF_T_TYPE. > Otherwise we need to handle the pad like yury do it in > stat.h, and we need to handle the bigendian as well: I see. > @@ -35,12 +35,21 @@ struct stat > { > __dev_t st_dev; /* Device. */ > #ifdef __ILP32__ > + > +#if !defined(__AARCH64EB__) > unsigned int __st_ino_pad; > +#endif > + > # ifndef __USE_FILE_OFFSET64 > __ino_t st_ino; /* File serial number. */ > # else > __ino_t __st_ino; /* 32bit file serial number. */ > # endif > + > +#if defined(__AARCH64EB__) > + unsigned int __st_ino_pad; > +#endif > + > #else This would indeed be silly, we really don't want anyone to access the old __st_ino field or the 32-bit version of the offset here. Arnd
On Tue, Mar 29, 2016 at 12:58:25PM +0200, Arnd Bergmann wrote: > On Saturday 26 March 2016 20:36:43 Zhangjian wrote: > > Hi, Arnd > > > > On 2016/3/21 17:43, Arnd Bergmann wrote: > > > On Monday 21 March 2016 10:07:49 Andreas Schwab wrote: > > >> This patch may fix a few LTP tests. > > >> > > > > > > Thanks for analyzing. > > > > > >> diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h > > >> index 3631903..d1010db 100644 > > >> --- a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h > > >> +++ b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h > > >> @@ -25,18 +25,29 @@ > > >> #define __O_NOFOLLOW 0100000 > > >> #define __O_DIRECT 0200000 > > >> > > >> -#define __O_LARGEFILE 0 > > >> +#ifdef __ILP32__ > > >> +# define __O_LARGEFILE 0400000 > > >> +#else > > >> +# define __O_LARGEFILE 0 > > >> +#endif > > >> > > > > > > I guess this means I screwed up when I said I'd merged the kernel patch > > > that Yury did to fix it, sorry about that. > > > > > > We need the patch to make all new architecture in the kernel default to > > > O_LARGEFILE, and not do this in user space. I'd suggest now to keep the > > > patches as part of the ILP32 series after all, to make sure they are > > > merged at the point when they are needed. > > > > I am a little bit confuse about off_t. In "[PATCH 08/33] 32-bit > > ABI: introduce ARCH_32BIT_OFF_T config option", it mentioned that all > > the new 32bit architecture should use 64bit off_t. > > Ah, so it is part of the series. I had not checked that here. > I'm preparing new submission now. I can join off_t, s390 and ilp32 patchsets. It seems, they will not be grabbed separately anyway, so this may decrease confusions like this. Arnd? > > Should we define off_t in aarch64(for both ilp32 and lp64) in > > typesize.h as following? > > > > diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > > index 7073493..13b77c5 100644 > > --- a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > > +++ b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > > @@ -33,7 +33,7 @@ > > #define __INO64_T_TYPE __UQUAD_TYPE > > #define __MODE_T_TYPE __U32_TYPE > > #define __NLINK_T_TYPE __U32_TYPE > > -#define __OFF_T_TYPE __SLONGWORD_TYPE > > +#define __OFF_T_TYPE __SQUAD_TYPE > > #define __OFF64_T_TYPE __SQUAD_TYPE > > #define __PID_T_TYPE __S32_TYPE > > #define __RLIM_T_TYPE __ULONGWORD_TYPE > > > > Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in > > aarch64. And truncate and ftruncate is same as truncate64 and > > ftruncate64. > > I don't know what the glibc developers prefer, but I think the > result needs to be something like that: either __OFF_T_TYPE is > defined as you write above as a 64-bit type, or the user-visible > off_t typedef unconditionally uses __OFF64_T_TYPE rather than > __OFF_T_TYPE. > I'm not the glibc developer as well, but I think it's OK. > > Otherwise we need to handle the pad like yury do it in > > stat.h, and we need to handle the bigendian as well: > > I see. > > > @@ -35,12 +35,21 @@ struct stat > > { > > __dev_t st_dev; /* Device. */ > > #ifdef __ILP32__ > > + > > +#if !defined(__AARCH64EB__) > > unsigned int __st_ino_pad; > > +#endif > > + > > # ifndef __USE_FILE_OFFSET64 > > __ino_t st_ino; /* File serial number. */ > > # else > > __ino_t __st_ino; /* 32bit file serial number. */ > > # endif > > + > > +#if defined(__AARCH64EB__) > > + unsigned int __st_ino_pad; > > +#endif > > + > > #else > > This would indeed be silly, we really don't want anyone > to access the old __st_ino field or the 32-bit version of > the offset here. > > Arnd
On Tuesday 29 March 2016 15:01:47 Yury Norov wrote: > On Tue, Mar 29, 2016 at 12:58:25PM +0200, Arnd Bergmann wrote: > > On Saturday 26 March 2016 20:36:43 Zhangjian wrote: > > > > > > I am a little bit confuse about off_t. In "[PATCH 08/33] 32-bit > > > ABI: introduce ARCH_32BIT_OFF_T config option", it mentioned that all > > > the new 32bit architecture should use 64bit off_t. > > > > Ah, so it is part of the series. I had not checked that here. > > > > I'm preparing new submission now. I can join off_t, s390 and ilp32 > patchsets. It seems, they will not be grabbed separately anyway, so > this may decrease confusions like this. > > Arnd? Yes, that sounds good. > > > Should we define off_t in aarch64(for both ilp32 and lp64) in > > > typesize.h as following? > > > > > > diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > > > index 7073493..13b77c5 100644 > > > --- a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > > > +++ b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > > > @@ -33,7 +33,7 @@ > > > #define __INO64_T_TYPE __UQUAD_TYPE > > > #define __MODE_T_TYPE __U32_TYPE > > > #define __NLINK_T_TYPE __U32_TYPE > > > -#define __OFF_T_TYPE __SLONGWORD_TYPE > > > +#define __OFF_T_TYPE __SQUAD_TYPE > > > #define __OFF64_T_TYPE __SQUAD_TYPE > > > #define __PID_T_TYPE __S32_TYPE > > > #define __RLIM_T_TYPE __ULONGWORD_TYPE > > > > > > Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in > > > aarch64. And truncate and ftruncate is same as truncate64 and > > > ftruncate64. > > > > I don't know what the glibc developers prefer, but I think the > > result needs to be something like that: either __OFF_T_TYPE is > > defined as you write above as a 64-bit type, or the user-visible > > off_t typedef unconditionally uses __OFF64_T_TYPE rather than > > __OFF_T_TYPE. > > > > I'm not the glibc developer as well, but I think it's OK. Which of the two? I guess with the example that Bamvor gave regarding struct stat, the latter is what we want, forcing the use of __USE_FILE_OFFSET64 rather than changing the definition of __OFF_T_TYPE. Arnd
Hi, Yury On 2016/3/29 20:01, Yury Norov wrote: > On Tue, Mar 29, 2016 at 12:58:25PM +0200, Arnd Bergmann wrote: >> On Saturday 26 March 2016 20:36:43 Zhangjian wrote: >>> Hi, Arnd >>> >>> On 2016/3/21 17:43, Arnd Bergmann wrote: >>>> On Monday 21 March 2016 10:07:49 Andreas Schwab wrote: >>>>> This patch may fix a few LTP tests. >>>>> >>>> >>>> Thanks for analyzing. >>>> >>>>> diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h >>>>> index 3631903..d1010db 100644 >>>>> --- a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h >>>>> +++ b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h >>>>> @@ -25,18 +25,29 @@ >>>>> #define __O_NOFOLLOW 0100000 >>>>> #define __O_DIRECT 0200000 >>>>> >>>>> -#define __O_LARGEFILE 0 >>>>> +#ifdef __ILP32__ >>>>> +# define __O_LARGEFILE 0400000 >>>>> +#else >>>>> +# define __O_LARGEFILE 0 >>>>> +#endif >>>>> >>>> >>>> I guess this means I screwed up when I said I'd merged the kernel patch >>>> that Yury did to fix it, sorry about that. >>>> >>>> We need the patch to make all new architecture in the kernel default to >>>> O_LARGEFILE, and not do this in user space. I'd suggest now to keep the >>>> patches as part of the ILP32 series after all, to make sure they are >>>> merged at the point when they are needed. >>> >>> I am a little bit confuse about off_t. In "[PATCH 08/33] 32-bit >>> ABI: introduce ARCH_32BIT_OFF_T config option", it mentioned that all >>> the new 32bit architecture should use 64bit off_t. >> >> Ah, so it is part of the series. I had not checked that here. >> > > I'm preparing new submission now. Cool:) > I can join off_t, s390 and ilp32 > patchsets. It seems, they will not be grabbed separately anyway, so > this may decrease confusions like this. > > Arnd? I am curious which one is more easily to get ack:p > >>> Should we define off_t in aarch64(for both ilp32 and lp64) in >>> typesize.h as following? >>> >>> diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h >>> index 7073493..13b77c5 100644 >>> --- a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h >>> +++ b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h >>> @@ -33,7 +33,7 @@ >>> #define __INO64_T_TYPE __UQUAD_TYPE >>> #define __MODE_T_TYPE __U32_TYPE >>> #define __NLINK_T_TYPE __U32_TYPE >>> -#define __OFF_T_TYPE __SLONGWORD_TYPE >>> +#define __OFF_T_TYPE __SQUAD_TYPE >>> #define __OFF64_T_TYPE __SQUAD_TYPE >>> #define __PID_T_TYPE __S32_TYPE >>> #define __RLIM_T_TYPE __ULONGWORD_TYPE >>> >>> Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in >>> aarch64. And truncate and ftruncate is same as truncate64 and >>> ftruncate64. >> >> I don't know what the glibc developers prefer, but I think the >> result needs to be something like that: either __OFF_T_TYPE is >> defined as you write above as a 64-bit type, or the user-visible >> off_t typedef unconditionally uses __OFF64_T_TYPE rather than >> __OFF_T_TYPE. >> > > I'm not the glibc developer as well, but I think it's OK. IIUC, it is usually what glibc does. If we want to define off_t to 64bit in ilp32, the follow syscall may need to define as non-compat too: sys_fadvise64 sys_sendfile sys_sendfile64 sys_lseek sys_splice sys_sync_file_range2 sys_truncate sys_ftruncate Regards Bamvor > >>> Otherwise we need to handle the pad like yury do it in >>> stat.h, and we need to handle the bigendian as well: >> >> I see. >> >>> @@ -35,12 +35,21 @@ struct stat >>> { >>> __dev_t st_dev; /* Device. */ >>> #ifdef __ILP32__ >>> + >>> +#if !defined(__AARCH64EB__) >>> unsigned int __st_ino_pad; >>> +#endif >>> + >>> # ifndef __USE_FILE_OFFSET64 >>> __ino_t st_ino; /* File serial number. */ >>> # else >>> __ino_t __st_ino; /* 32bit file serial number. */ >>> # endif >>> + >>> +#if defined(__AARCH64EB__) >>> + unsigned int __st_ino_pad; >>> +#endif >>> + >>> #else >> >> This would indeed be silly, we really don't want anyone >> to access the old __st_ino field or the 32-bit version of >> the offset here. >> >> Arnd
On Tuesday 29 March 2016 21:21:49 Zhangjian wrote: > >>> > >>> Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in > >>> aarch64. And truncate and ftruncate is same as truncate64 and > >>> ftruncate64. > >> > >> I don't know what the glibc developers prefer, but I think the > >> result needs to be something like that: either __OFF_T_TYPE is > >> defined as you write above as a 64-bit type, or the user-visible > >> off_t typedef unconditionally uses __OFF64_T_TYPE rather than > >> __OFF_T_TYPE. > >> > > > > I'm not the glibc developer as well, but I think it's OK. > IIUC, it is usually what glibc does. > If we want to define off_t to 64bit in ilp32, the follow syscall may > need to define as non-compat too: > sys_fadvise64 > sys_sendfile > sys_sendfile64 > sys_lseek > sys_splice > sys_sync_file_range2 > sys_truncate > sys_ftruncate I'm not following here. Do you mean in the kernel or in glibc? In the kernel, the list of syscalls is fine, because we already only provide syscalls passing loff_t as I said, and that is 64-bit. In glibc, I think we need to define fewer entry points, not more. Instead of having both lseek and lseek64, only one of them should be provided, and that should always take a 64-bit offset, calling into the kernel with the _llseek syscall entry. Arnd
On Tue, 29 Mar 2016, Arnd Bergmann wrote: > In glibc, I think we need to define fewer entry points, not more. > Instead of having both lseek and lseek64, only one of them should > be provided, and that should always take a 64-bit offset, calling > into the kernel with the _llseek syscall entry. lseek64 is part of the public API, on all platforms. It should be aliased to lseek where possible. Strictly, it would be possible to provide it in the API without it being part of the ABI, by arranging the headers so that calls to lseek64 result in objects with a reference to lseek (because it uses the off64_t typedef, it's not valid to declare it yourself rather than including a header that declares it). I don't think it would be a good idea for a new sub-architecture port to try introducing such a difference from all other ports, however.
On Tuesday 29 March 2016 15:54:52 Joseph Myers wrote: > On Tue, 29 Mar 2016, Arnd Bergmann wrote: > > > In glibc, I think we need to define fewer entry points, not more. > > Instead of having both lseek and lseek64, only one of them should > > be provided, and that should always take a 64-bit offset, calling > > into the kernel with the _llseek syscall entry. > > lseek64 is part of the public API, on all platforms. It should be aliased > to lseek where possible. Right, makes sense. > Strictly, it would be possible to provide it in the API without it being > part of the ABI, by arranging the headers so that calls to lseek64 result > in objects with a reference to lseek (because it uses the off64_t typedef, > it's not valid to declare it yourself rather than including a header that > declares it). I don't think it would be a good idea for a new > sub-architecture port to try introducing such a difference from all other > ports, however. How do we do it then? Should we just define __USE_FILE_OFFSET64 unconditionally for all new 32-bit architectures and leave the code dealing with 32-bit off_t/ino_t in place but unreachable, to minimize the differences? Or should all the obsolete types be defined the same way as their replacements so we have 64-bit __OFF_T_TYPE/__INO_T_TYPE and use the same binary implementation regardless of FILE_OFFSET_BITS? Arnd
On Tue, 29 Mar 2016, Arnd Bergmann wrote: > How do we do it then? Should we just define __USE_FILE_OFFSET64 > unconditionally for all new 32-bit architectures and leave the > code dealing with 32-bit off_t/ino_t in place but unreachable, to > minimize the differences? Defining __USE_FILE_OFFSET64 unconditionally would prevent glibc from building (see: how the patches a while back prototyping changing the default had to disable the change when glibc itself is built). A change in the default, though desired (someone needs to pick up those patches together with the analysis done of possible impact on distributions), should not be tied to a new port, and would need to be discussed thoroughly on libc-alpha. > Or should all the obsolete types be defined the same way as their > replacements so we have 64-bit __OFF_T_TYPE/__INO_T_TYPE > and use the same binary implementation regardless of FILE_OFFSET_BITS? I think so (along with using wordsize-64 sysdeps directories as far as possible, like x32 does). But design questions for a glibc port really belong on libc-alpha to get any sort of community consensus.
On Tuesday 29 March 2016 20:15:10 Joseph Myers wrote: > On Tue, 29 Mar 2016, Arnd Bergmann wrote: > > > How do we do it then? Should we just define __USE_FILE_OFFSET64 > > unconditionally for all new 32-bit architectures and leave the > > code dealing with 32-bit off_t/ino_t in place but unreachable, to > > minimize the differences? > > Defining __USE_FILE_OFFSET64 unconditionally would prevent glibc from > building (see: how the patches a while back prototyping changing the > default had to disable the change when glibc itself is built). A change > in the default, though desired (someone needs to pick up those patches > together with the analysis done of possible impact on distributions), > should not be tied to a new port, and would need to be discussed > thoroughly on libc-alpha. Ok > > Or should all the obsolete types be defined the same way as their > > replacements so we have 64-bit __OFF_T_TYPE/__INO_T_TYPE > > and use the same binary implementation regardless of FILE_OFFSET_BITS? > > I think so (along with using wordsize-64 sysdeps directories as far as > possible, like x32 does). But design questions for a glibc port really > belong on libc-alpha to get any sort of community consensus. I thought the wordsize-64 stuff was for the x86 mode where they define __kernel_long_t as 64-bit. We don't really want to do that in the kernel for new 32-bit architectures, that would make the kernel ABI different from all the existing architectures. The kernel ABI for ilp32 follows the usual wordsize-32 definitions to make it easy for glibc while avoiding the problems that came from redefining __kernel_long_t. Arnd
On Tue, 29 Mar 2016, Arnd Bergmann wrote: > > I think so (along with using wordsize-64 sysdeps directories as far as > > possible, like x32 does). But design questions for a glibc port really > > belong on libc-alpha to get any sort of community consensus. > > I thought the wordsize-64 stuff was for the x86 mode where they > define __kernel_long_t as 64-bit. We don't really want to do that in > the kernel for new 32-bit architectures, that would make the kernel > ABI different from all the existing architectures. In general the wordsize-64 directories cover various relations of the form "function X is an alias for function Y", which derive from "type X is ABI-compatible with type Y". (Unfortunately, the precise set isn't well-defined, resulting in problems for cases that want a subset of those relations - e.g. MIPS n64 where struct stat and struct stat64 are different, and so sysdeps/unix/sysv/linux/wordsize-64 isn't used.) The person doing the port will need to do a detailed review of the exact effects of the wordsize-64 directories in current glibc, and which of those effects are appropriate for this port, to determine what is appropriate, and to include that analysis with the port submission. Many of the relations relate to things controlled by _FILE_OFFSET_BITS=64 - if _FILE_OFFSET_BITS=64 does not affect the ABI of off_t, struct stat, etc., then many of the aliases are correct. Some relations may relate to other things such as long and long long being ABI compatible - where an alias in the correct direction can be OK for long arguments (not returns) if a long argument is always sign-extended to long long when passed to a function, for example.
On Tuesday 29 March 2016 21:00:56 Joseph Myers wrote: > On Tue, 29 Mar 2016, Arnd Bergmann wrote: > > > > I think so (along with using wordsize-64 sysdeps directories as far as > > > possible, like x32 does). But design questions for a glibc port really > > > belong on libc-alpha to get any sort of community consensus. > > > > I thought the wordsize-64 stuff was for the x86 mode where they > > define __kernel_long_t as 64-bit. We don't really want to do that in > > the kernel for new 32-bit architectures, that would make the kernel > > ABI different from all the existing architectures. > > In general the wordsize-64 directories cover various relations of the form > "function X is an alias for function Y", which derive from "type X is > ABI-compatible with type Y". (Unfortunately, the precise set isn't > well-defined, resulting in problems for cases that want a subset of those > relations - e.g. MIPS n64 where struct stat and struct stat64 are > different, and so sysdeps/unix/sysv/linux/wordsize-64 isn't used.) For all new 32-bit architectures like this, the kernel should at least behave in a consistent way, but it's somewhere inbetween wordsize-32 and wordsize-64 for 32-bit architectures, because off_t and ino_t are mapped to the 64-bit __kernel_loff_t and __kernel_ino_t, while time_t, clock_t and size_t are mapped to 32 bit types. > The person doing the port will need to do a detailed review of the exact > effects of the wordsize-64 directories in current glibc, and which of > those effects are appropriate for this port, to determine what is > appropriate, and to include that analysis with the port submission. I think the analysis will have to be about two separate things: * Whether new 32-bit architectures in general should use wordsize-32 or wordsize-64 or something else, based on what you write above. I would still guess that we are better off adapting wordsize-32 to the current kernel ABI for 32-bit architectures while leaving wordsize-64 to real 64-bit architectures and x86/x32. * How we deal with the special case of this architecture having nonstandard calling conventions for a couple of syscalls that take 64-bit arguments in a single register rather than two registers as every other 32-bit architecture does. Arnd
On 2016/3/29 21:27, Arnd Bergmann wrote: > On Tuesday 29 March 2016 21:21:49 Zhangjian wrote: >>>>> >>>>> Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in >>>>> aarch64. And truncate and ftruncate is same as truncate64 and >>>>> ftruncate64. >>>> >>>> I don't know what the glibc developers prefer, but I think the >>>> result needs to be something like that: either __OFF_T_TYPE is >>>> defined as you write above as a 64-bit type, or the user-visible >>>> off_t typedef unconditionally uses __OFF64_T_TYPE rather than >>>> __OFF_T_TYPE. >>>> >>> >>> I'm not the glibc developer as well, but I think it's OK. >> IIUC, it is usually what glibc does. >> If we want to define off_t to 64bit in ilp32, the follow syscall may >> need to define as non-compat too: >> sys_fadvise64 >> sys_sendfile >> sys_sendfile64 >> sys_lseek >> sys_splice >> sys_sync_file_range2 >> sys_truncate >> sys_ftruncate > > I'm not following here. Do you mean in the kernel or in glibc? kernel. > > In the kernel, the list of syscalls is fine, because we already only > provide syscalls passing loff_t as I said, and that is 64-bit. Sorry I am lost here. I understand that the syscall passing loff_t should wrap to 64bit syscall. But if we define off_t as 64bit, then all the offset relative syscall should wrap to 64bit syscall. > > In glibc, I think we need to define fewer entry points, not more. > Instead of having both lseek and lseek64, only one of them should > be provided, and that should always take a 64-bit offset, calling > into the kernel with the _llseek syscall entry. Agree. We should avoid the duplicated definition. Regards Bamvor > > Arnd >
diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h index 7073493..13b77c5 100644 --- a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h +++ b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h @@ -33,7 +33,7 @@ #define __INO64_T_TYPE __UQUAD_TYPE #define __MODE_T_TYPE __U32_TYPE #define __NLINK_T_TYPE __U32_TYPE -#define __OFF_T_TYPE __SLONGWORD_TYPE +#define __OFF_T_TYPE __SQUAD_TYPE #define __OFF64_T_TYPE __SQUAD_TYPE #define __PID_T_TYPE __S32_TYPE #define __RLIM_T_TYPE __ULONGWORD_TYPE Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in aarch64. And truncate and ftruncate is same as truncate64 and ftruncate64. Otherwise we need to handle the pad like yury do it in stat.h, and we need to handle the bigendian as well: From 61949bf70527b9cc450e7bbdba9182f7f120c5bd Sun March 26 00:00:00 2016 From: j00321192 <jijun2@huawei.com> Date: Thu, 24 Mar 2016 22:10:25 +0800 Subject: [PATCH] Fix endian issue in struct stat and stat64 There is endian issue in the existence bits/stat.h in aarch64. Fix it by add the __AARCH64EB__ with proper pad. Tested in our arm64 hardware. It could fix all the *stat test cases. Signed-off-by: Yongliang Gao <gaoyongliang@huawei.com> Signed-off-by: Jun Ji <jijun2@huawei.com> Signed-off-by: Yang Liu(Young) <young.liuyang@huawei.com> Signed-off-by: Zhang Jian(Bamvor) <bamvor.zhangjian@huawei.com> --- sysdeps/unix/sysv/linux/aarch64/bits/stat.h | 38 +++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 5 deletions(-) diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/stat.h b/sysdeps/unix/sysv/linux/aarch64/bits/stat.h index 3d50e7a..4c6e072 100644 --- a/sysdeps/unix/sysv/linux/aarch64/bits/stat.h +++ b/sysdeps/unix/sysv/linux/aarch64/bits/stat.h @@ -35,12 +35,21 @@ struct stat { __dev_t st_dev; /* Device. */ #ifdef __ILP32__ + +#if !defined(__AARCH64EB__) unsigned int __st_ino_pad; +#endif + # ifndef __USE_FILE_OFFSET64 __ino_t st_ino; /* File serial number. */ # else __ino_t __st_ino; /* 32bit file serial number. */ # endif + +#if defined(__AARCH64EB__) + unsigned int __st_ino_pad; +#endif + #else # ifndef __USE_FILE_OFFSET64 __ino_t st_ino; /* File serial number. */ @@ -55,10 +64,17 @@ struct stat __dev_t st_rdev; /* Device number, if device. */ __dev_t __pad1; #ifndef __USE_FILE_OFFSET64 + +#if defined(__ILP32__) && defined(__AARCH64EB__) + int __st_size_pad; +#endif + __off_t st_size; /* Size of file, in bytes. */ -# ifdef __ILP32__ + +#if defined(__ILP32__) && !defined(__AARCH64EB__) int __st_size_pad; -# endif +#endif + #else __off64_t st_size; /* Size of file, in bytes. */ #endif @@ -66,10 +82,17 @@ struct stat int __pad2; #ifndef __USE_FILE_OFFSET64 + +#if defined (__ILP32__) && defined(__AARCH64EB__) + int __st_blocks_pad; +#endif + __blkcnt_t st_blocks; /* Number 512-byte blocks allocated. */ -# ifdef __ILP32__ + +#if defined (__ILP32__) && !defined(__AARCH64EB__) int __st_blocks_pad; -# endif +#endif + #else __blkcnt64_t st_blocks; /* Number 512-byte blocks allocated. */ #endif @@ -94,7 +117,7 @@ struct stat __time_t st_ctime; /* Time of last status change. */ unsigned long int st_ctimensec; /* Nsecs of last status change. */ #endif -#if !defined __ILP32__ || !defined __USE_FILE_OFFSET64 +#if !defined (__ILP32__) || !defined __USE_FILE_OFFSET64 int __glibc_reserved[2]; #else __ino64_t st_ino; /* File serial number. */ @@ -106,8 +129,13 @@ struct stat64 { __dev_t st_dev; /* Device. */ # ifdef __ILP32__ + #if !defined(__AARCH64EB__) unsigned int __st_ino_pad; + #endif __ino_t __st_ino; /* 32bit file serial number. */ + #if defined(__AARCH64EB__) + unsigned int __st_ino_pad; + #endif # else __ino64_t st_ino; /* File serial number. */ # endif