All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH v3 00/13] Glibc OpenRISC port
Date: Sun, 26 Dec 2021 07:44:28 +0900	[thread overview]
Message-ID: <YceezKrlAWqcnpS0@antec> (raw)
In-Reply-To: <CAAfxs75QcK2VkXOtbR70y9SjcNnqvNtTMq0bt+8M1az3A_LVPg@mail.gmail.com>

On Sat, Dec 25, 2021 at 04:24:35PM +0900, Stafford Horne wrote:
> On Fri, Dec 24, 2021, 6:26 AM Stafford Horne <shorne@gmail.com> wrote:
> 
> > On Thu, Dec 23, 2021 at 04:57:56PM +0100, Andreas Schwab wrote:
> > > On Dez 24 2021, Stafford Horne via Libc-alpha wrote:
> > >
> > > > It seems the write to the tmp file was failing due the re-open not
> > passing
> > > > O_LARGEFILE.
> > >
> > > open64 implies O_LARGEFILE, so if that is making a difference, then your
> > > open64 is broken.
> >
> > Right, that is what the docs say.  This architecuture is 32-bits.
> >
> > And the open64 path is generic.
> >
> > Possibly this bit removing O_LARGEFILE is wrong?
> >
> > In sysdeps/unix/sysv/linux/open64.c:
> >
> >   27 #ifdef __OFF_T_MATCHES_OFF64_T
> >   28 # define EXTRA_OPEN_FLAGS 0
> >   29 #else
> >   30 # define EXTRA_OPEN_FLAGS O_LARGEFILE
> >   31 #endif
> >
> > Otherwise there is something is wrong on linux.  It is explicitly checking
> > for the precense of O_LARGEFILE.
> >
> > in fs/read_write.c in generic_write_check_limits:
> >
> >         if (!(file->f_flags & O_LARGEFILE))
> >                 max_size = MAX_NON_LFS;
> >
> 
> There's something wrong with __OFF_T_MATCHES_OFF64_T in this port.  We have
> 32-bit off_t in Linux.  So __OFF_T_MATCHES_OFF64_T should be undefined I
> think.  I'll look into.

So, __OFF_T_MATCHES_OFF64_T if defined if TIMESIZE==64 && WORDSIZE==32, and it's
correct from glibc's perspective as off_t is 64-bits in the user API.  However,
it is not correct for use for setting O_LARGEFILE.

In linux the O_LARGEFILE flag is forced based on architecture configuration
ARCH_32BIT_OFF_T.

    #define force_o_largefile() (!IS_ENABLED(CONFIG_ARCH_32BIT_OFF_T))

Then it is used in syscalls:

    SYSCALL_DEFINE4(openat, int, dfd, const char __user *, filename, int, flags,
		    umode_t, mode)
    {
	    if (force_o_largefile())
		    flags |= O_LARGEFILE;
	    return do_sys_open(dfd, filename, flags, mode);
    }

On most 32-bit architectures ARCH_32BIT_OFF_T is configured.  SO I think there
is something wrong with how we are setting up EXTRA_OPEN_FLAGS based on
__OFF_T_MATCHES_OFF64_T only.  Maybe it should be changed to WORDSIZE==32 or a
combination.  I will send a separate patch to discuss.

-Stafford

      reply	other threads:[~2021-12-25 22:44 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10 23:34 [OpenRISC] [PATCH v3 00/13] Glibc OpenRISC port Stafford Horne
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 01/13] elf: Add reloc for OpenRISC Stafford Horne
2021-12-14 20:28   ` Adhemerval Zanella
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 02/13] linux/syscalls: Add or1k_atomic syscall " Stafford Horne
2021-12-14 20:29   ` Adhemerval Zanella
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 03/13] or1k: ABI Implementation Stafford Horne
2021-12-14 20:53   ` Adhemerval Zanella
2021-12-14 22:43     ` Joseph Myers
2021-12-15  1:15       ` Adhemerval Zanella
2021-12-15 23:33         ` Stafford Horne
2021-12-16 10:30           ` Adhemerval Zanella
2021-12-16 21:28     ` Stafford Horne
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 04/13] or1k: startup and dynamic linking code Stafford Horne
2021-12-16 10:42   ` Adhemerval Zanella
2021-12-17 23:03     ` Stafford Horne
2021-12-20 19:45       ` Adhemerval Zanella
2021-12-20 21:40         ` Stafford Horne
2021-12-21 11:09           ` Adhemerval Zanella
2021-12-21 11:46             ` Stafford Horne
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 05/13] or1k: Thread Local Storage support Stafford Horne
2021-12-16 11:35   ` Adhemerval Zanella
2021-12-16 12:37   ` Adhemerval Zanella
2021-12-16 19:26     ` Joseph Myers
2021-12-16 19:33       ` Adhemerval Zanella
2021-12-17 14:23     ` Stafford Horne
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 06/13] or1k: Atomics and Locking primitives Stafford Horne
2021-12-16 12:52   ` Adhemerval Zanella
2021-12-16 19:43     ` Adhemerval Zanella
2021-12-17 15:03       ` Stafford Horne
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 07/13] or1k: math soft float support Stafford Horne
2021-12-16 19:48   ` Adhemerval Zanella
2021-12-17 15:02     ` Stafford Horne
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 08/13] or1k: Linux Syscall Interface Stafford Horne
2021-12-16 21:17   ` Adhemerval Zanella
2021-12-17 15:01     ` Stafford Horne
2021-12-17 17:41       ` Adhemerval Zanella
2021-12-20 11:53         ` Stafford Horne
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 09/13] or1k: Linux ABI Stafford Horne
2021-12-21 13:41   ` Adhemerval Zanella
2021-12-21 14:54     ` Stafford Horne
2021-12-22 10:54       ` Stafford Horne
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 10/13] or1k: ABI lists Stafford Horne
2021-12-22 20:20   ` Adhemerval Zanella
2021-12-23  8:36     ` Stafford Horne
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 11/13] or1k: Build Infrastructure Stafford Horne
2021-12-22 21:03   ` Adhemerval Zanella
2021-12-23  7:32     ` Stafford Horne
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 12/13] build-many-glibcs.py: add OpenRISC support Stafford Horne
2021-12-22 21:04   ` Adhemerval Zanella
2021-12-23  7:15     ` Stafford Horne
2021-12-10 23:34 ` [OpenRISC] [PATCH v3 13/13] Documentation for OpenRISC port Stafford Horne
2021-12-23 12:57   ` Adhemerval Zanella
2021-12-14 20:25 ` [OpenRISC] [PATCH v3 00/13] Glibc " Adhemerval Zanella
2021-12-15  1:19   ` Adhemerval Zanella
2021-12-15  5:34     ` Stafford Horne
2021-12-15  5:37   ` Stafford Horne
2021-12-23 15:46     ` Stafford Horne
2021-12-23 15:57       ` Andreas Schwab
2021-12-23 21:26         ` Stafford Horne
2021-12-25  7:24           ` Stafford Horne
2021-12-25 22:44             ` Stafford Horne [this message]

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=YceezKrlAWqcnpS0@antec \
    --to=shorne@gmail.com \
    --cc=openrisc@lists.librecores.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.