From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: linux-man <linux-man@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Libc-alpha <libc-alpha@sourceware.org>
Subject: outb(2) Text regarding optimizations
Date: Wed, 6 Oct 2021 21:14:48 +0200 [thread overview]
Message-ID: <3db43b50-a0a5-ed0e-4def-e44f845f8e89@gmail.com> (raw)
Hi,
outb(2) says that users of these functions should optimize to avoid
having unresolved references at link time.
The text is:
[
They are primarily designed for internal kernel use, but
can be used from user space.
You must compile with -O or -O2 or similar. The functions
are defined as inline macros, and will not be substituted
in without optimization enabled, causing unresolved refer‐
ences at link time.
]
First of all, "inline macros" already is a misnomer. They are 'static
inline' functions. But 'static inline' functions _never_ cause
unresolved references, because they are 'static', so the function code
is added to each translation unit as an anonymous function (which is a
big problem of static inline: it may bloat code by repeating code in
translation units, C99 inline being preferable).
So is this an incorrect advice (maybe because of a veeery old
implementation)? (I couldn't find any relevant implementation changes
in the glibc git history.)
If there is any reason I'm missing (I don't understand the assembly
calls that these functions call, so maybe) that would cause these
functions to actually require optimization, I'd say it's a bug, and a
better solution would be to add the attribute
__attribute__((__always_inline__)) to the functions, so that they will
_always_ be inlined, no matter what optimization level the user chooses.
Right?
Thanks,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
reply other threads:[~2021-10-06 19:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3db43b50-a0a5-ed0e-4def-e44f845f8e89@gmail.com \
--to=alx.manpages@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox