public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
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