* stat64 on mips
@ 2013-12-30 18:20 Justin Cormack
2013-12-30 21:29 ` Rich Felker
0 siblings, 1 reply; 8+ messages in thread
From: Justin Cormack @ 2013-12-30 18:20 UTC (permalink / raw)
To: musl
MIPS is the most confusing architecture, but as far as I can make out,
the definition of struct stat64 that Musl has is probably the right
one for mips n32 but wrong for mips o32 which should be
struct stat {
unsigned long st_dev;
unsigned long __st_pad0[3];
unsigned long long st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
unsigned long st_rdev;
unsigned long __st_pad1[3];
long long st_size;
time_t st_atime;
unsigned long st_atime_nsec;
time_t st_mtime;
unsigned long st_mtime_nsec;
time_t st_ctime;
unsigned long st_ctime_nsec;
unsigned long st_blksize;
unsigned long __st_pad2;
long long st_blocks;
};
It does appear that the syscalls for the two ABIs differ in this...
Justin
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: stat64 on mips 2013-12-30 18:20 stat64 on mips Justin Cormack @ 2013-12-30 21:29 ` Rich Felker 2013-12-30 22:02 ` Justin Cormack 0 siblings, 1 reply; 8+ messages in thread From: Rich Felker @ 2013-12-30 21:29 UTC (permalink / raw) To: musl On Mon, Dec 30, 2013 at 06:20:46PM +0000, Justin Cormack wrote: > MIPS is the most confusing architecture, but as far as I can make out, > the definition of struct stat64 that Musl has is probably the right > one for mips n32 but wrong for mips o32 which should be > > struct stat { > unsigned long st_dev; > unsigned long __st_pad0[3]; > unsigned long long st_ino; > mode_t st_mode; > nlink_t st_nlink; > uid_t st_uid; > gid_t st_gid; > unsigned long st_rdev; > unsigned long __st_pad1[3]; > long long st_size; > time_t st_atime; > unsigned long st_atime_nsec; > time_t st_mtime; > unsigned long st_mtime_nsec; > time_t st_ctime; > unsigned long st_ctime_nsec; > unsigned long st_blksize; > unsigned long __st_pad2; > long long st_blocks; > }; > > It does appear that the syscalls for the two ABIs differ in this... This structure is identical to the one in musl except that it has 32-bit dev_t plus padding in place of 64-bit dev_t, and the musl version has reserved space at the end. Can you check whether the dev_t issue is actually a problem (it might be, based on endianness, and if so I think it would require ugly fixups in userspace)? Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: stat64 on mips 2013-12-30 21:29 ` Rich Felker @ 2013-12-30 22:02 ` Justin Cormack 2013-12-30 22:03 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: Justin Cormack @ 2013-12-30 22:02 UTC (permalink / raw) To: musl On Mon, Dec 30, 2013 at 9:29 PM, Rich Felker <dalias@aerifal.cx> wrote: > On Mon, Dec 30, 2013 at 06:20:46PM +0000, Justin Cormack wrote: >> MIPS is the most confusing architecture, but as far as I can make out, >> the definition of struct stat64 that Musl has is probably the right >> one for mips n32 but wrong for mips o32 which should be >> >> struct stat { >> unsigned long st_dev; >> unsigned long __st_pad0[3]; >> unsigned long long st_ino; >> mode_t st_mode; >> nlink_t st_nlink; >> uid_t st_uid; >> gid_t st_gid; >> unsigned long st_rdev; >> unsigned long __st_pad1[3]; >> long long st_size; >> time_t st_atime; >> unsigned long st_atime_nsec; >> time_t st_mtime; >> unsigned long st_mtime_nsec; >> time_t st_ctime; >> unsigned long st_ctime_nsec; >> unsigned long st_blksize; >> unsigned long __st_pad2; >> long long st_blocks; >> }; >> >> It does appear that the syscalls for the two ABIs differ in this... > > This structure is identical to the one in musl except that it has > 32-bit dev_t plus padding in place of 64-bit dev_t, and the musl > version has reserved space at the end. Can you check whether the dev_t > issue is actually a problem (it might be, based on endianness, and if > so I think it would require ugly fixups in userspace)? Ah no, my mistake, you are right, the padding seems correct and I was getting confused as usual by dev_t. However the 64 bit dev_t is a problem on bigendian mips. (Whats the reason for Musl using 64 bit dev_t? glibc compatibility?) justin ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: stat64 on mips 2013-12-30 22:02 ` Justin Cormack @ 2013-12-30 22:03 ` Rich Felker 2013-12-30 22:10 ` Justin Cormack 0 siblings, 1 reply; 8+ messages in thread From: Rich Felker @ 2013-12-30 22:03 UTC (permalink / raw) To: musl On Mon, Dec 30, 2013 at 10:02:19PM +0000, Justin Cormack wrote: > On Mon, Dec 30, 2013 at 9:29 PM, Rich Felker <dalias@aerifal.cx> wrote: > > On Mon, Dec 30, 2013 at 06:20:46PM +0000, Justin Cormack wrote: > >> MIPS is the most confusing architecture, but as far as I can make out, > >> the definition of struct stat64 that Musl has is probably the right > >> one for mips n32 but wrong for mips o32 which should be > >> > >> struct stat { > >> unsigned long st_dev; > >> unsigned long __st_pad0[3]; > >> unsigned long long st_ino; > >> mode_t st_mode; > >> nlink_t st_nlink; > >> uid_t st_uid; > >> gid_t st_gid; > >> unsigned long st_rdev; > >> unsigned long __st_pad1[3]; > >> long long st_size; > >> time_t st_atime; > >> unsigned long st_atime_nsec; > >> time_t st_mtime; > >> unsigned long st_mtime_nsec; > >> time_t st_ctime; > >> unsigned long st_ctime_nsec; > >> unsigned long st_blksize; > >> unsigned long __st_pad2; > >> long long st_blocks; > >> }; > >> > >> It does appear that the syscalls for the two ABIs differ in this... > > > > This structure is identical to the one in musl except that it has > > 32-bit dev_t plus padding in place of 64-bit dev_t, and the musl > > version has reserved space at the end. Can you check whether the dev_t > > issue is actually a problem (it might be, based on endianness, and if > > so I think it would require ugly fixups in userspace)? > > Ah no, my mistake, you are right, the padding seems correct and I was > getting confused as usual by dev_t. However the 64 bit dev_t is a > problem on bigendian mips. > > (Whats the reason for Musl using 64 bit dev_t? glibc compatibility?) And room for expansion, and consistency of the type between archs. There's no justification for dev_t or similar types to be arch-specific. Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: stat64 on mips 2013-12-30 22:03 ` Rich Felker @ 2013-12-30 22:10 ` Justin Cormack 2013-12-30 22:13 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: Justin Cormack @ 2013-12-30 22:10 UTC (permalink / raw) To: musl On Mon, Dec 30, 2013 at 10:03 PM, Rich Felker <dalias@aerifal.cx> wrote: > On Mon, Dec 30, 2013 at 10:02:19PM +0000, Justin Cormack wrote: >> On Mon, Dec 30, 2013 at 9:29 PM, Rich Felker <dalias@aerifal.cx> wrote: >> > On Mon, Dec 30, 2013 at 06:20:46PM +0000, Justin Cormack wrote: >> >> MIPS is the most confusing architecture, but as far as I can make out, >> >> the definition of struct stat64 that Musl has is probably the right >> >> one for mips n32 but wrong for mips o32 which should be >> >> >> >> struct stat { >> >> unsigned long st_dev; >> >> unsigned long __st_pad0[3]; >> >> unsigned long long st_ino; >> >> mode_t st_mode; >> >> nlink_t st_nlink; >> >> uid_t st_uid; >> >> gid_t st_gid; >> >> unsigned long st_rdev; >> >> unsigned long __st_pad1[3]; >> >> long long st_size; >> >> time_t st_atime; >> >> unsigned long st_atime_nsec; >> >> time_t st_mtime; >> >> unsigned long st_mtime_nsec; >> >> time_t st_ctime; >> >> unsigned long st_ctime_nsec; >> >> unsigned long st_blksize; >> >> unsigned long __st_pad2; >> >> long long st_blocks; >> >> }; >> >> >> >> It does appear that the syscalls for the two ABIs differ in this... >> > >> > This structure is identical to the one in musl except that it has >> > 32-bit dev_t plus padding in place of 64-bit dev_t, and the musl >> > version has reserved space at the end. Can you check whether the dev_t >> > issue is actually a problem (it might be, based on endianness, and if >> > so I think it would require ugly fixups in userspace)? >> >> Ah no, my mistake, you are right, the padding seems correct and I was >> getting confused as usual by dev_t. However the 64 bit dev_t is a >> problem on bigendian mips. >> >> (Whats the reason for Musl using 64 bit dev_t? glibc compatibility?) > > And room for expansion, and consistency of the type between archs. > There's no justification for dev_t or similar types to be > arch-specific. But isnt the kernel dev_t 32 bit for all archs? Justin ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: stat64 on mips 2013-12-30 22:10 ` Justin Cormack @ 2013-12-30 22:13 ` Rich Felker 2013-12-30 22:15 ` Justin Cormack 2013-12-30 22:53 ` Justin Cormack 0 siblings, 2 replies; 8+ messages in thread From: Rich Felker @ 2013-12-30 22:13 UTC (permalink / raw) To: musl On Mon, Dec 30, 2013 at 10:10:59PM +0000, Justin Cormack wrote: > On Mon, Dec 30, 2013 at 10:03 PM, Rich Felker <dalias@aerifal.cx> wrote: > > On Mon, Dec 30, 2013 at 10:02:19PM +0000, Justin Cormack wrote: > >> On Mon, Dec 30, 2013 at 9:29 PM, Rich Felker <dalias@aerifal.cx> wrote: > >> > On Mon, Dec 30, 2013 at 06:20:46PM +0000, Justin Cormack wrote: > >> >> MIPS is the most confusing architecture, but as far as I can make out, > >> >> the definition of struct stat64 that Musl has is probably the right > >> >> one for mips n32 but wrong for mips o32 which should be > >> >> > >> >> struct stat { > >> >> unsigned long st_dev; > >> >> unsigned long __st_pad0[3]; > >> >> unsigned long long st_ino; > >> >> mode_t st_mode; > >> >> nlink_t st_nlink; > >> >> uid_t st_uid; > >> >> gid_t st_gid; > >> >> unsigned long st_rdev; > >> >> unsigned long __st_pad1[3]; > >> >> long long st_size; > >> >> time_t st_atime; > >> >> unsigned long st_atime_nsec; > >> >> time_t st_mtime; > >> >> unsigned long st_mtime_nsec; > >> >> time_t st_ctime; > >> >> unsigned long st_ctime_nsec; > >> >> unsigned long st_blksize; > >> >> unsigned long __st_pad2; > >> >> long long st_blocks; > >> >> }; > >> >> > >> >> It does appear that the syscalls for the two ABIs differ in this... > >> > > >> > This structure is identical to the one in musl except that it has > >> > 32-bit dev_t plus padding in place of 64-bit dev_t, and the musl > >> > version has reserved space at the end. Can you check whether the dev_t > >> > issue is actually a problem (it might be, based on endianness, and if > >> > so I think it would require ugly fixups in userspace)? > >> > >> Ah no, my mistake, you are right, the padding seems correct and I was > >> getting confused as usual by dev_t. However the 64 bit dev_t is a > >> problem on bigendian mips. > >> > >> (Whats the reason for Musl using 64 bit dev_t? glibc compatibility?) > > > > And room for expansion, and consistency of the type between archs. > > There's no justification for dev_t or similar types to be > > arch-specific. > > But isnt the kernel dev_t 32 bit for all archs? Yes and no. They have adjacent padding reserved to make it up to 128-bit, despite the fact that intmax_t is 64-bit everywhere and thus 128-bit types can't really be used. I suspect on big-endian the padding is at the other side to allow for this already, but it might be misaligned with respect to the 64/128 bit size in musl at present. Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: stat64 on mips 2013-12-30 22:13 ` Rich Felker @ 2013-12-30 22:15 ` Justin Cormack 2013-12-30 22:53 ` Justin Cormack 1 sibling, 0 replies; 8+ messages in thread From: Justin Cormack @ 2013-12-30 22:15 UTC (permalink / raw) To: musl On Mon, Dec 30, 2013 at 10:13 PM, Rich Felker <dalias@aerifal.cx> wrote: > On Mon, Dec 30, 2013 at 10:10:59PM +0000, Justin Cormack wrote: >> On Mon, Dec 30, 2013 at 10:03 PM, Rich Felker <dalias@aerifal.cx> wrote: >> > On Mon, Dec 30, 2013 at 10:02:19PM +0000, Justin Cormack wrote: >> >> On Mon, Dec 30, 2013 at 9:29 PM, Rich Felker <dalias@aerifal.cx> wrote: >> >> > On Mon, Dec 30, 2013 at 06:20:46PM +0000, Justin Cormack wrote: >> >> >> MIPS is the most confusing architecture, but as far as I can make out, >> >> >> the definition of struct stat64 that Musl has is probably the right >> >> >> one for mips n32 but wrong for mips o32 which should be >> >> >> >> >> >> struct stat { >> >> >> unsigned long st_dev; >> >> >> unsigned long __st_pad0[3]; >> >> >> unsigned long long st_ino; >> >> >> mode_t st_mode; >> >> >> nlink_t st_nlink; >> >> >> uid_t st_uid; >> >> >> gid_t st_gid; >> >> >> unsigned long st_rdev; >> >> >> unsigned long __st_pad1[3]; >> >> >> long long st_size; >> >> >> time_t st_atime; >> >> >> unsigned long st_atime_nsec; >> >> >> time_t st_mtime; >> >> >> unsigned long st_mtime_nsec; >> >> >> time_t st_ctime; >> >> >> unsigned long st_ctime_nsec; >> >> >> unsigned long st_blksize; >> >> >> unsigned long __st_pad2; >> >> >> long long st_blocks; >> >> >> }; >> >> >> >> >> >> It does appear that the syscalls for the two ABIs differ in this... >> >> > >> >> > This structure is identical to the one in musl except that it has >> >> > 32-bit dev_t plus padding in place of 64-bit dev_t, and the musl >> >> > version has reserved space at the end. Can you check whether the dev_t >> >> > issue is actually a problem (it might be, based on endianness, and if >> >> > so I think it would require ugly fixups in userspace)? >> >> >> >> Ah no, my mistake, you are right, the padding seems correct and I was >> >> getting confused as usual by dev_t. However the 64 bit dev_t is a >> >> problem on bigendian mips. >> >> >> >> (Whats the reason for Musl using 64 bit dev_t? glibc compatibility?) >> > >> > And room for expansion, and consistency of the type between archs. >> > There's no justification for dev_t or similar types to be >> > arch-specific. >> >> But isnt the kernel dev_t 32 bit for all archs? > > Yes and no. They have adjacent padding reserved to make it up to > 128-bit, despite the fact that intmax_t is 64-bit everywhere and thus > 128-bit types can't really be used. I suspect on big-endian the > padding is at the other side to allow for this already, but it might > be misaligned with respect to the 64/128 bit size in musl at present. Let me just double check on both endians. Maybe I made a mistake... Justin ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: stat64 on mips 2013-12-30 22:13 ` Rich Felker 2013-12-30 22:15 ` Justin Cormack @ 2013-12-30 22:53 ` Justin Cormack 1 sibling, 0 replies; 8+ messages in thread From: Justin Cormack @ 2013-12-30 22:53 UTC (permalink / raw) To: musl On Mon, Dec 30, 2013 at 10:13 PM, Rich Felker <dalias@aerifal.cx> wrote: > On Mon, Dec 30, 2013 at 10:10:59PM +0000, Justin Cormack wrote: >> On Mon, Dec 30, 2013 at 10:03 PM, Rich Felker <dalias@aerifal.cx> wrote: >> > On Mon, Dec 30, 2013 at 10:02:19PM +0000, Justin Cormack wrote: >> >> On Mon, Dec 30, 2013 at 9:29 PM, Rich Felker <dalias@aerifal.cx> wrote: >> >> > On Mon, Dec 30, 2013 at 06:20:46PM +0000, Justin Cormack wrote: >> >> >> MIPS is the most confusing architecture, but as far as I can make out, >> >> >> the definition of struct stat64 that Musl has is probably the right >> >> >> one for mips n32 but wrong for mips o32 which should be >> >> >> >> >> >> struct stat { >> >> >> unsigned long st_dev; >> >> >> unsigned long __st_pad0[3]; >> >> >> unsigned long long st_ino; >> >> >> mode_t st_mode; >> >> >> nlink_t st_nlink; >> >> >> uid_t st_uid; >> >> >> gid_t st_gid; >> >> >> unsigned long st_rdev; >> >> >> unsigned long __st_pad1[3]; >> >> >> long long st_size; >> >> >> time_t st_atime; >> >> >> unsigned long st_atime_nsec; >> >> >> time_t st_mtime; >> >> >> unsigned long st_mtime_nsec; >> >> >> time_t st_ctime; >> >> >> unsigned long st_ctime_nsec; >> >> >> unsigned long st_blksize; >> >> >> unsigned long __st_pad2; >> >> >> long long st_blocks; >> >> >> }; >> >> >> >> >> >> It does appear that the syscalls for the two ABIs differ in this... >> >> > >> >> > This structure is identical to the one in musl except that it has >> >> > 32-bit dev_t plus padding in place of 64-bit dev_t, and the musl >> >> > version has reserved space at the end. Can you check whether the dev_t >> >> > issue is actually a problem (it might be, based on endianness, and if >> >> > so I think it would require ugly fixups in userspace)? >> >> >> >> Ah no, my mistake, you are right, the padding seems correct and I was >> >> getting confused as usual by dev_t. However the 64 bit dev_t is a >> >> problem on bigendian mips. >> >> >> >> (Whats the reason for Musl using 64 bit dev_t? glibc compatibility?) >> > >> > And room for expansion, and consistency of the type between archs. >> > There's no justification for dev_t or similar types to be >> > arch-specific. >> >> But isnt the kernel dev_t 32 bit for all archs? > > Yes and no. They have adjacent padding reserved to make it up to > 128-bit, despite the fact that intmax_t is 64-bit everywhere and thus > 128-bit types can't really be used. I suspect on big-endian the > padding is at the other side to allow for this already, but it might > be misaligned with respect to the 64/128 bit size in musl at present. I am having toolchain trouble with my machine. Just ignore until I can replicate after reinstalling with a more recent Linux than the one it shipped with. Justin ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-12-30 22:53 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-12-30 18:20 stat64 on mips Justin Cormack 2013-12-30 21:29 ` Rich Felker 2013-12-30 22:02 ` Justin Cormack 2013-12-30 22:03 ` Rich Felker 2013-12-30 22:10 ` Justin Cormack 2013-12-30 22:13 ` Rich Felker 2013-12-30 22:15 ` Justin Cormack 2013-12-30 22:53 ` Justin Cormack
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).