public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Zack Weinberg <zackw@panix.com>
To: Yury Norov <ynorov@caviumnetworks.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [RFC PATCH] __fxstat: replace if() with #if when checking version
Date: Tue, 06 Sep 2016 16:47:00 -0000	[thread overview]
Message-ID: <CAKCAbMgXGYaZvmf+fyg5FEEiuN=uur5aCTa0Xvb0QeHHZgnXfg@mail.gmail.com> (raw)
In-Reply-To: <1473166521-24827-1-git-send-email-ynorov@caviumnetworks.com>

On Tue, Sep 6, 2016 at 8:55 AM, Yury Norov <ynorov@caviumnetworks.com> wrote:
> __fxstat() is always passed with _STAT_VER as vers parameter and it's
> in internal namespace.
>
> It means we can replace runtime argument check with compile-time #ifdef.
> It helps to make the body of _fxstat() smaller, and suppresses errors
> if struct kernel_stat or __xstat_conv() is not declared, when they
> are not needed.

We can't do this.  I think you may have already figured this out, but
let me write out a clear explanation for the benefit of future people
who may have the same idea.

_STAT_VER exists because the contents of struct stat have changed over
time.  When an old executable is used with a new C library, the 'vers'
argument will indicate that the executable expects the old layout, and
the library will translate from the kernel's (presumably newer) stat
layout to the executable's older expectations.  It is the same problem
that the kernel solves by changing the syscall numbers for
stat/fstat/lstat whenever they change the structure.  Therefore, the
'vers' argument *can* vary at runtime, even though all the code in the
*current* source tree always passes the same value.

To make this work, we have inline functions in <sys/stat.h>, backed up
by out-of-line copies in libc_nonshared.a, that present the documented
API (stat/fstat/lstat) and call __xstat/__fxstat/__lxstat with the
additional argument.  That is why these __-name functions are part of
the public ABI for libc.so.  Same principle as __printf_chk for
instance.

If we were designing this mechanism today from scratch we would
probably use symbol versions - unless there's some nonobvious reason
why that wouldn't work - but this mechanism *predates* symbol
versioning.  It has been around since the 1990s if not earlier.  Maybe
you could look into arranging to use symbol versions from now (or
better, the next time the kernel changes the stat structure) going
forward.  But the old __(|f|l)xstat symbols need to stick around for
binary compatibility, and their implementations need to test their
'vers' argument at runtime.

zw

      parent reply	other threads:[~2016-09-06 16:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-06 12:55 Yury Norov
2016-09-06 13:09 ` Andreas Schwab
2016-09-06 15:59   ` Yury Norov
2016-09-06 16:06     ` Yury Norov
2016-09-06 16:47 ` Zack Weinberg [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='CAKCAbMgXGYaZvmf+fyg5FEEiuN=uur5aCTa0Xvb0QeHHZgnXfg@mail.gmail.com' \
    --to=zackw@panix.com \
    --cc=libc-alpha@sourceware.org \
    --cc=ynorov@caviumnetworks.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).