public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Evan Green <evan@rivosinc.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org, vineetg@rivosinc.com,
	slewis@rivosinc.com,  palmer@rivosinc.com
Subject: Re: [PATCH v12 2/7] linux: Introduce INTERNAL_VSYSCALL
Date: Fri, 23 Feb 2024 15:12:31 -0800	[thread overview]
Message-ID: <CALs-Hsu8B05YL2-6GanDdRLqtxPK=xf4eLPJ4xbD0K=Y5YcVhg@mail.gmail.com> (raw)
In-Reply-To: <877cj47t0f.fsf@oldenburg.str.redhat.com>

On Thu, Feb 15, 2024 at 11:44 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Evan Green:
>
> > Add an INTERNAL_VSYSCALL() macro that makes a vDSO call, falling back to
> > a regular syscall, but without setting errno. Instead, the return value
> > is plumbed straight out of the macro.
> >
> > Signed-off-by: Evan Green <evan@rivosinc.com>
> > ---
> >
> > (no changes since v10)
> >
> > Changes in v10:
> >  - Introduced INTERNAL_VSYSCALL patch
> >
> >  sysdeps/unix/sysv/linux/sysdep-vdso.h | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/sysdeps/unix/sysv/linux/sysdep-vdso.h b/sysdeps/unix/sysv/linux/sysdep-vdso.h
> > index 189319ad98..f7d4b29b25 100644
> > --- a/sysdeps/unix/sysv/linux/sysdep-vdso.h
> > +++ b/sysdeps/unix/sysv/linux/sysdep-vdso.h
> > @@ -53,4 +53,23 @@
> >      sc_ret;                                                                \
> >    })
> >
> > +#define INTERNAL_VSYSCALL(name, nr, args...)                               \
> > +  ({                                                                       \
> > +    __label__ out;                                                         \
> > +    long int sc_ret;                                                       \
> > +                                                                           \
> > +    __typeof (GLRO(dl_vdso_##name)) vdsop = GLRO(dl_vdso_##name);          \
> > +    if (vdsop != NULL)                                                             \
> > +      {                                                                            \
> > +     sc_ret = INTERNAL_VSYSCALL_CALL (vdsop, nr, ##args);                  \
> > +     if ((!INTERNAL_SYSCALL_ERROR_P (sc_ret)) ||                           \
> > +         (INTERNAL_SYSCALL_ERRNO (sc_ret) != ENOSYS))                      \
> > +       goto out;                                                           \
> > +      }                                                                            \
> > +                                                                           \
> > +    sc_ret = INTERNAL_SYSCALL_CALL (name, ##args);                         \
> > +  out:                                                                             \
> > +    sc_ret;                                                                \
> > +  })
> > +
> >  #endif /* SYSDEP_VDSO_LINUX_H  */
>
> I wonder if this is clearer without the label and with a conditional
> expression instead?

It's kinda awkward without the label because the regular syscall is
made either if vdsop is NULL or returns ENOSYS (which is two checks on
the return value, so doesn't lend itself to inlining in the if
statement). The best I could come up with without the label is to
duplicate the syscall_call:

#define INTERNAL_VSYSCALL(name, nr, args...)                      \
  ({                                          \
    long int sc_ret;                                  \
                                          \
    __typeof (GLRO(dl_vdso_##name)) vdsop = GLRO(dl_vdso_##name);          \
    if (vdsop != NULL)                                  \
      {                                          \
    sc_ret = INTERNAL_VSYSCALL_CALL (vdsop, nr, ##args);              \
    if ((INTERNAL_SYSCALL_ERROR_P (sc_ret)) &&                  \
        (INTERNAL_SYSCALL_ERRNO (sc_ret) == ENOSYS))              \
      sc_ret = INTERNAL_SYSCALL_CALL (name, ##args);              \
      }                                          \
    else                                      \
      {                                          \
    sc_ret = INTERNAL_SYSCALL_CALL (name, ##args);                  \
      }                                          \
    sc_ret;                                      \
  })

I think I prefer the version with the label, but I'm not attuned to
the glibc style, so let me know if you like this and I'll send out a
new version.
-Evan

  reply	other threads:[~2024-02-23 23:13 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14 14:31 [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface Evan Green
2024-02-14 14:31 ` [PATCH v12 1/7] riscv: Add Linux hwprobe syscall support Evan Green
2024-02-14 14:31 ` [PATCH v12 2/7] linux: Introduce INTERNAL_VSYSCALL Evan Green
2024-02-16  7:44   ` Florian Weimer
2024-02-23 23:12     ` Evan Green [this message]
2024-02-23 23:29       ` Gabriel Ravier
2024-02-24  2:06         ` Richard Henderson
2024-02-24 11:40       ` Florian Weimer
2024-02-26 16:47         ` Evan Green
2024-02-26 17:07           ` Florian Weimer
2024-02-26 17:57             ` Evan Green
2024-02-14 14:31 ` [PATCH v12 3/7] riscv: Add hwprobe vdso call support Evan Green
2024-02-14 14:31 ` [PATCH v12 4/7] riscv: Add __riscv_hwprobe pointer to ifunc calls Evan Green
2024-02-14 14:31 ` [PATCH v12 5/7] riscv: Enable multi-arg ifunc resolvers Evan Green
2024-02-16  7:45   ` Florian Weimer
2024-02-14 14:31 ` [PATCH v12 6/7] riscv: Add ifunc helper method to hwprobe.h Evan Green
2024-02-14 14:31 ` [PATCH v12 7/7] riscv: Add and use alignment-ignorant memcpy Evan Green
2024-02-14 15:16 ` [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface Adhemerval Zanella Netto
2024-02-14 15:24   ` Andreas Schwab
2024-02-22 18:44     ` Palmer Dabbelt
2024-02-15 15:48   ` Evan Green
2024-02-15 15:57     ` enh
2024-02-15 16:50     ` Palmer Dabbelt
2024-02-15 17:00       ` enh
2024-02-15 17:22         ` Palmer Dabbelt
2024-02-15 18:45           ` enh
2024-02-15 18:56             ` Palmer Dabbelt
2024-02-15 17:42       ` Jessica Clarke
2024-02-15 18:52         ` enh
2024-02-15 19:09           ` Jessica Clarke
2024-02-22 19:41             ` Palmer Dabbelt

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='CALs-Hsu8B05YL2-6GanDdRLqtxPK=xf4eLPJ4xbD0K=Y5YcVhg@mail.gmail.com' \
    --to=evan@rivosinc.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=palmer@rivosinc.com \
    --cc=slewis@rivosinc.com \
    --cc=vineetg@rivosinc.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).