From: Alistair Francis <alistair23@gmail.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
GNU C Library <libc-alpha@sourceware.org>,
Arnd Bergmann <arnd@arndb.de>,
Adhemerval Zanella <adhemerval.zanella@linaro.org>,
Florian Weimer <fweimer@redhat.com>,
Palmer Dabbelt <palmer@sifive.com>,
macro@wdc.com, Zong Li <zongbox@gmail.com>
Subject: Re: [RFC v4 08/24] sysdeps/stat: Copy the statx struct to stat instead of stat64
Date: Mon, 12 Aug 2019 23:10:00 -0000 [thread overview]
Message-ID: <CAKmqyKN4f0NhxHACaGmoghZLq9e6JHhFPXqiXJmnmp5skR36UQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1908122252080.18203@digraph.polyomino.org.uk>
On Mon, Aug 12, 2019 at 4:02 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Mon, 12 Aug 2019, Alistair Francis wrote:
>
> > > * The layout of struct stat and struct stat64 is identical, except that
> > > some bytes that are padding in struct stat serve as high parts of fields
> > > that are wider in struct stat64 (and thus have endian-dependent positions
> > > as determined by the __field64 macro in bits/stat.h).
> >
> > __ino_t is a 64-bit value in RV32, so in both stat and stat64 it's the
> > same thing. The __pad1 changes in size between the two structs as one
> > is a short and one is just an int. I don't see how they are identical.
>
> What file are you looking at, in what version of the source tree?
I'm looking at sysdeps/unix/sysv/linux/bits/stat.h, it has a different
definition then the one you are looking at.
>
> I'm looking at sysdeps/unix/sysv/linux/generic/bits/stat.h. As far as I
> can tell, your patch series doesn't change that file. That's the version
> used by RV64 and it should be used by RV32 (the headers installed for RV32
> and RV64 should be identical apart from the special cases of
> gnu/lib-names-*.h and gnu/stubs-*.h; if it isn't, that needs to be fixed).
It looks like __field64(__ino_t, __ino64_t, st_ino) will use type int
for RV32 (I don't think __USE_FILE_OFFSET64 is defined) which might
need some changes.
>
> In that file, __pad1 is of type __dev_t in both struct stat and struct
> stat64.
In the file you are looking at that is correct.
>
> > > If those types are 64-bit, you should not have padding around them in
> > > struct stat, so as to preserve the property that struct stat and struct
> > > stat64 have the same layout. I suppose this means bits/stat.h needs to
> > > check further macros such as __OFF_T_MATCHES_OFF64_T.
> >
> > Changing the padding would fix the problem. Just to be clear is that
> > what you are suggesting?
>
> Yes.
>
> Either change the definition of __field64, or the uses of it.
Yep, in the file you are looking at that seems the best way to go.
>
> Changing the definition runs into the complication that it's used three
> times and each has its own macro to say whether the two types in question
> match, but you could always have a #error if some match and others don't.
>
> > > You'll also need to ensure that XSTAT_IS_XSTAT64 is defined to 1. And
> > > you'll need to make wordsize-32/overflow.h define trivial versions of the
> > > *_overflow functions in cases where the types match (this should be done
> > > in that file, rather than making an RV32-specific copy, to benefit future
> > > ports that make the same choices as RV32).
> >
> > I think I tested that and it didn't fix the problem so I dropped it.
> > I'll add the XSTAT_IS_XSTAT64 define back.
> >
> > I'm not sure what you mean by then the types match?
>
> off_t and off64_t match if they have the same size and alignment (if
> __OFF_T_MATCHES_OFF64_T is defined). Likewise for the other pairs.
>
> If off_t and off64_t match, there is no need for the "buf->__st_size_pad
> == 0" check in stat_overflow (and once you've removed the padding in that
> case, that check won't even compile because __st_size_pad won't exist).
> Likewise for the other pairs. In practice, you can probably just make
> that function return 0 if all three macros are defined, rather than
> allowing for arbitrary subsets of the types matching or not matching.
Ok, I think I understand. I'll update the patch series.
>
> Similar considerations apply to statfs_overflow if the types and padding
> used in struct statfs match those used in struct statfs64. So apply
> similar considerations to the two versions of that structure.
Ok
Alistair
>
> You probably don't need to do anything special with lseek_overflow because
> the compiler should just optimize that away when off_t and loff_t are the
> same type.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
next prev parent reply other threads:[~2019-08-12 23:10 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-10 1:03 [RFC v4 00/24] RISC-V glibc port for the 32-bit Alistair Francis
2019-08-10 1:03 ` [RFC v4 07/24] time: Deprecate struct timezone members Alistair Francis
2019-08-10 1:20 ` Paul Eggert
2019-08-10 1:30 ` Alistair Francis
2019-08-11 13:52 ` Florian Weimer
2019-08-11 16:59 ` Alistair Francis
2019-08-11 17:28 ` Rich Felker
2019-08-12 8:22 ` Florian Weimer
2019-08-12 15:42 ` Zack Weinberg
2019-08-12 20:20 ` Joseph Myers
2019-08-12 21:08 ` Zack Weinberg
2019-08-12 21:26 ` Joseph Myers
2019-08-12 22:13 ` Alistair Francis
2019-08-12 23:16 ` Zack Weinberg
2019-08-13 0:53 ` Paul Eggert
2019-08-13 1:04 ` Zack Weinberg
2019-08-12 22:11 ` Alistair Francis
2019-08-10 1:03 ` [RFC v4 05/24] sysdeps/clock_gettime: Use clock_gettime64 if avaliable Alistair Francis
2019-08-12 19:46 ` Joseph Myers
2019-08-13 23:48 ` Alistair Francis
2019-08-14 16:37 ` Joseph Myers
2019-08-14 18:12 ` Alistair Francis
2019-08-10 1:03 ` [RFC v4 02/24] sysdeps/nanosleep: Use clock_nanosleep_time64 " Alistair Francis
2019-08-12 17:22 ` Joseph Myers
2019-08-14 18:24 ` Alistair Francis
2019-08-14 20:15 ` Joseph Myers
2019-08-14 21:39 ` Stepan Golosunov
2019-08-10 1:03 ` [RFC v4 17/24] RISC-V: Hard float support for the 32 bit Alistair Francis
2019-08-10 1:03 ` [RFC v4 12/24] RISC-V: define __NR_* as __NR_*_time64/64 for 32-bit Alistair Francis
2019-08-10 1:03 ` [RFC v4 15/24] RISC-V: Add path of library directories for RV32 Alistair Francis
2019-08-10 1:03 ` [RFC v4 13/24] RISC-V: Use 64-bit timespec in clock_gettime vdso calls Alistair Francis
2019-08-10 1:03 ` [RFC v4 08/24] sysdeps/stat: Copy the statx struct to stat instead of stat64 Alistair Francis
2019-08-12 20:01 ` Joseph Myers
2019-08-12 22:26 ` Alistair Francis
2019-08-12 23:02 ` Joseph Myers
2019-08-12 23:10 ` Alistair Francis [this message]
2019-08-12 23:31 ` Joseph Myers
2019-08-13 20:40 ` Alistair Francis
2019-08-10 1:03 ` [RFC v4 16/24] RISC-V: The ABI implementation for the 32-bit Alistair Francis
2019-08-10 1:03 ` [RFC v4 10/24] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Alistair Francis
2019-08-10 1:03 ` [RFC v4 09/24] Documentation for the RISC-V 32-bit port Alistair Francis
2019-08-12 20:02 ` Joseph Myers
2019-08-10 1:03 ` [RFC v4 04/24] sysdeps/wait: Use waitid if avaliable Alistair Francis
2019-08-10 1:03 ` [RFC v4 06/24] sysdeps/timespec_get: Use clock_gettime64 " Alistair Francis
2019-08-12 19:46 ` Joseph Myers
2019-08-15 18:03 ` Alistair Francis
2019-08-15 19:46 ` Joseph Myers
2019-08-15 20:52 ` Alistair Francis
2019-08-15 20:59 ` Joseph Myers
2019-08-15 21:16 ` Alistair Francis
2019-08-15 21:19 ` Joseph Myers
2019-08-15 21:23 ` Alistair Francis
2019-08-15 21:28 ` Joseph Myers
2019-08-15 21:35 ` Alistair Francis
2019-08-10 1:03 ` [RFC v4 01/24] sunrpc/clnt_udp: Ensure total_deadline is initalised Alistair Francis
2019-08-10 1:03 ` [RFC v4 03/24] sysdeps/gettimeofday: Use clock_gettime64 if avaliable Alistair Francis
2019-08-12 17:27 ` Joseph Myers
2019-08-10 1:04 ` [RFC v4 22/24] RISC-V: Use 64-bit vdso syscalls for RV32 Alistair Francis
2019-08-10 1:04 ` [RFC v4 18/24] RISC-V: Add ABI lists Alistair Francis
2019-08-10 1:04 ` [RFC v4 19/24] RISC-V: Build Infastructure for the 32-bit Alistair Francis
2019-08-10 1:04 ` [RFC v4 11/24] RISC-V: define __NR_futex as __NR_futex_time64 for 32-bit Alistair Francis
2019-08-10 1:04 ` [RFC v4 20/24] RISC-V: Fix llrint and llround missing exceptions on RV32 Alistair Francis
2019-08-10 1:04 ` [RFC v4 21/24] Add RISC-V 32-bit target to build-many-glibcs.py Alistair Francis
2019-08-10 1:04 ` [RFC v4 14/24] RISC-V: Support dynamic loader for the 32-bit Alistair Francis
2019-08-10 1:04 ` [RFC v4 24/24] timerfd_settime: Use 64-bit call if avaliable Alistair Francis
2019-08-10 1:28 ` Alistair Francis
2019-08-20 20:11 ` Maciej W. Rozycki
2019-08-12 20:09 ` Joseph Myers
2019-08-10 1:04 ` [RFC v4 23/24] WIP: syscall.list: Call 64-bit versions of syscalls Alistair Francis
2019-08-14 18:39 ` Alistair Francis
2019-08-14 18:57 ` Florian Weimer
2019-08-15 21:43 ` Alistair Francis
2019-08-19 11:30 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKmqyKN4f0NhxHACaGmoghZLq9e6JHhFPXqiXJmnmp5skR36UQ@mail.gmail.com \
--to=alistair23@gmail.com \
--cc=adhemerval.zanella@linaro.org \
--cc=alistair.francis@wdc.com \
--cc=arnd@arndb.de \
--cc=fweimer@redhat.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=macro@wdc.com \
--cc=palmer@sifive.com \
--cc=zongbox@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).