Re: outb(2): terminology correction

Re: outb(2): terminology correction

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

[CC += GENERIC INCLUDE/ASM HEADER FILES maintainers]

Hi astian, Arnd,

> Date: 2026-08-31 09:09:46+0000
> From: astian <astian@memeware.net>
>
> outb(2) says:
> 
>   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 references at link time.
> 
> "inline macros [...] not substituted in without optimization" doesn't
> make any sense.  C pre-processor macros cannot be inline or not inline.
> Indeed these are inline *functions* (at least in this system) with
> embedded assembly apparently referencing parameters (which, I surmise,
> is why the functions need to be inlined by the compiler or the assembly
> will not work).
> 
> From /usr/include/x86_64-linux-gnu/sys/io.h (glibc 2.43):
> 
>   [...]
>   #if defined __GNUC__ && __GNUC__ >= 2
> 
>   static __inline unsigned char
>   inb (unsigned short int __port)
>   {
>     unsigned char _v;
> 
>     __asm__ __volatile__ ("inb %w1,%0":"=a" (_v):"Nd" (__port));
>     return _v;
>   }
> 
>   [...]
> 
>   static __inline void
>   outb (unsigned char __value, unsigned short int __port)
>   {
>     __asm__ __volatile__ ("outb %b0,%w1": :"a" (__value), "Nd" (__port));
>   }
> 
>   [...]
> 
> So I would say just s/inline macros/inline functions/g.

Yes, 'inline functions' seems more appropriate than 'inline macros' (all
macros are inlined, due to how the preprocessor works, so they'd be just
macros, and as you showed, these are not even macros --except maybe in
some architectures--).

However, I doubt the entire paragraph.  I don't know why inline
functions would produce unresolved references at link time _even if they
were not substituted_.  The point of inline functions is that they are
sometimes inlined, and sometimes not, and the compiler does the right
thing in both cases.

This seems like paranoia from decades ago, when inline functions were
less known (and maybe compilers were more buggy than they are now).

Arnd, should we remove the paragraph entirely?  Or is there any obscure
reason why optimizations are required?


Have a lovely day!
Alex 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: outb(2): terminology correction

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2672 bytes --]

> Date: 2026-09-11 13:36:29+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> [CC += GENERIC INCLUDE/ASM HEADER FILES maintainers]
> 
> Hi astian, Arnd,
> 
> > Date: 2026-08-31 09:09:46+0000
> > From: astian <astian@memeware.net>
> >
> > outb(2) says:
> > 
> >   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 references at link time.
> > 
> > "inline macros [...] not substituted in without optimization" doesn't
> > make any sense.  C pre-processor macros cannot be inline or not inline.
> > Indeed these are inline *functions* (at least in this system) with
> > embedded assembly apparently referencing parameters (which, I surmise,
> > is why the functions need to be inlined by the compiler or the assembly
> > will not work).
> > 
> > From /usr/include/x86_64-linux-gnu/sys/io.h (glibc 2.43):
> > 
> >   [...]
> >   #if defined __GNUC__ && __GNUC__ >= 2
> > 
> >   static __inline unsigned char
> >   inb (unsigned short int __port)
> >   {
> >     unsigned char _v;
> > 
> >     __asm__ __volatile__ ("inb %w1,%0":"=a" (_v):"Nd" (__port));
> >     return _v;
> >   }
> > 
> >   [...]
> > 
> >   static __inline void
> >   outb (unsigned char __value, unsigned short int __port)
> >   {
> >     __asm__ __volatile__ ("outb %b0,%w1": :"a" (__value), "Nd" (__port));
> >   }
> > 
> >   [...]
> > 
> > So I would say just s/inline macros/inline functions/g.
> 
> Yes, 'inline functions' seems more appropriate than 'inline macros' (all
> macros are inlined, due to how the preprocessor works, so they'd be just
> macros, and as you showed, these are not even macros --except maybe in
> some architectures--).
> 
> However, I doubt the entire paragraph.  I don't know why inline
> functions would produce unresolved references at link time _even if they
> were not substituted_.  The point of inline functions is that they are
> sometimes inlined, and sometimes not, and the compiler does the right
> thing in both cases.
> 
> This seems like paranoia from decades ago, when inline functions were
> less known (and maybe compilers were more buggy than they are now).
> 
> Arnd, should we remove the paragraph entirely?  Or is there any obscure
> reason why optimizations are required?

Or maybe those assembly instructions are what causes the linker issues?
If so, we should probably say something about that.


Cheers,
Alex

> 
> 
> Have a lovely day!
> Alex 
> 
> -- 
> <https://www.alejandro-colomar.es>



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: outb(2): terminology correction

[Arnd Bergmann]

On Fri, Sep 11, 2026, at 13:36, Alejandro Colomar wrote:
>> Date: 2026-08-31 09:09:46+0000
>> From: astian <astian@memeware.net>

> Yes, 'inline functions' seems more appropriate than 'inline macros' (all
> macros are inlined, due to how the preprocessor works, so they'd be just
> macros, and as you showed, these are not even macros --except maybe in
> some architectures--).
>
> However, I doubt the entire paragraph.  I don't know why inline
> functions would produce unresolved references at link time _even if they
> were not substituted_.  The point of inline functions is that they are
> sometimes inlined, and sometimes not, and the compiler does the right
> thing in both cases.
>
> This seems like paranoia from decades ago, when inline functions were
> less known (and maybe compilers were more buggy than they are now).

My best guess is that this described a bug in glibc that was fixed in
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=994cc0ea88ce7a33d532b735c0723705742b1a7e

commit 994cc0ea88ce7a33d532b735c0723705742b1a7e
Author: Andreas Jaeger <aj@suse.de>
Date:   Wed Aug 23 16:57:31 2000 +0000

    (_EXTERN_INLINE): Remove. Use static __inline instead of _EXTERN_INLINE.

--- a/sysdeps/unix/sysv/linux/i386/sys/io.h
+++ b/sysdeps/unix/sysv/linux/i386/sys/io.h
@@ -40,12 +40,7 @@ extern int iopl (int __level) __THROW;
 
 #if defined __GNUC__ && __GNUC__ >= 2
 
-# ifndef _EXTERN_INLINE
-#  define _EXTERN_INLINE extern __inline
-# endif
-
-
-_EXTERN_INLINE unsigned char
+static __inline unsigned char
 inb (unsigned short int port)
 {
   unsigned char _v;
...

Using 'extern __inline' without optimization in --std=gnu89 would lead to
the compiler using an 'extern' reference rather than emitting a static
version, the 'static __inline' variant works as intended in both gnu
and standard c99.

> Arnd, should we remove the paragraph entirely?  Or is there any obscure
> reason why optimizations are required?

Yes, removing it seems best to me. If you're changing the file, I would
suggest also adding a note that the interfaces are nonportable and only
work on x86 and alpha. 32-bit arm has an empty stub implementation for
sys/io.h, everything else doesn't seem to have anything in glibc here.

       Arnd

[PATCH v1] man/man2/outb.2: Remove obsolete note about optimizations

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

It seems this was necessary due to an old glibc bug, fixed in glibc.git
994cc0ea88ce (2000-08-23; "(_EXTERN_INLINE): Remove. Use static __inline
instead of _EXTERN_INLINE.").

Link: <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=994cc0ea88ce7a33d532b735c0723705742b1a7e>
Reported-by: astian <astian@memeware.net>
Reported-by: Alejandro Colomar <alx@kernel.org>
Cc: Andreas Jaeger <aj@suse.de>
Cc: Linux-Arch <linux-arch@vger.kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Message-ID: <b6258140-1ece-4113-bcb4-025302ef59cc@app.fastmail.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
---

Hi Arnd,

Thanks for confirming!  I've taken that as an 'Acked-by'.

I'll also prepare a commit for mentioning the non-portability, and the
archs that support this.  Thanks for that suggestion!


Have a lovely day!
Alex

 man/man2/outb.2 | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/man/man2/outb.2 b/man/man2/outb.2
index 98bd6bab4ffa..ba87455b121f 100644
--- a/man/man2/outb.2
+++ b/man/man2/outb.2
@@ -62,15 +62,6 @@ .SH DESCRIPTION
 .\" in addition to that given in
 .\" .BR outb (9).
 .P
-You must compile with
-.B \-O
-or
-.B \-O2
-or similar.
-The functions
-are defined as inline macros, and will not be substituted in without
-optimization enabled, causing unresolved references at link time.
-.P
 You use
 .BR ioperm (2)
 or alternatively

base-commit: bd51589ffe65f720d9618bffef5da00938e9842e
-- 
2.55.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: outb(2): terminology correction

[astian]

On 11 Sep 2026 13:43 +0200, Alejandro Colomar wrote:
>> Date: 2026-09-11 13:36:29+0200
>> From: Alejandro Colomar <alx@kernel.org>
>>
>> [CC += GENERIC INCLUDE/ASM HEADER FILES maintainers]
>> 
>> Hi astian, Arnd,
>> 
>> > Date: 2026-08-31 09:09:46+0000
>> > From: astian <astian@memeware.net>
>> >
>> > outb(2) says:
>> >
>> >   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 references at link time.
>> >
>> > "inline macros [...] not substituted in without optimization" doesn't
>> > make any sense.  C pre-processor macros cannot be inline or not inline.
>> > Indeed these are inline *functions* (at least in this system) with
>> > embedded assembly apparently referencing parameters (which, I surmise,
>> > is why the functions need to be inlined by the compiler or the assembly
>> > will not work).
>> >
>> > From /usr/include/x86_64-linux-gnu/sys/io.h (glibc 2.43):
>> >
>> >   [...]
>> >   #if defined __GNUC__ && __GNUC__ >= 2
>> >
>> >   static __inline unsigned char
>> >   inb (unsigned short int __port)
>> >   {
>> >     unsigned char _v;
>> >
>> >     __asm__ __volatile__ ("inb %w1,%0":"=a" (_v):"Nd" (__port));
>> >     return _v;
>> >   }
>> >
>> >   [...]
>> >
>> >   static __inline void
>> >   outb (unsigned char __value, unsigned short int __port)
>> >   {
>> >     __asm__ __volatile__ ("outb %b0,%w1": :"a" (__value), "Nd" (__port));
>> >   }
>> >
>> >   [...]
>> >
>> > So I would say just s/inline macros/inline functions/g.
>>
>> Yes, 'inline functions' seems more appropriate than 'inline macros' (all
>> macros are inlined, due to how the preprocessor works, so they'd be just
>> macros, and as you showed, these are not even macros --except maybe in
>> some architectures--).
>>
>> However, I doubt the entire paragraph.  I don't know why inline
>> functions would produce unresolved references at link time _even if they
>> were not substituted_.  The point of inline functions is that they are
>> sometimes inlined, and sometimes not, and the compiler does the right
>> thing in both cases.
>>
>> This seems like paranoia from decades ago, when inline functions were
>> less known (and maybe compilers were more buggy than they are now).
>>
>> Arnd, should we remove the paragraph entirely?  Or is there any obscure
>> reason why optimizations are required?
>
> Or maybe those assembly instructions are what causes the linker issues?
> If so, we should probably say something about that.

I had a closer look and I now think that's not the case.  These
instructions work fine even if the function is not inlined.  See more
below.

On 11 Sep 2026 14:20 +0200, Arnd Bergmann wrote:
> My best guess is that this described a bug in glibc that was fixed in
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=994cc0ea88ce7a33d532b735c0723705742b1a7e
>
> commit 994cc0ea88ce7a33d532b735c0723705742b1a7e
> Author: Andreas Jaeger <aj@suse.de>
> Date:   Wed Aug 23 16:57:31 2000 +0000
>
>     (_EXTERN_INLINE): Remove. Use static __inline instead of _EXTERN_INLINE.
>
> --- a/sysdeps/unix/sysv/linux/i386/sys/io.h
> +++ b/sysdeps/unix/sysv/linux/i386/sys/io.h
> @@ -40,12 +40,7 @@ extern int iopl (int __level) __THROW;
>  
>  #if defined __GNUC__ && __GNUC__ >= 2
>  
> -# ifndef _EXTERN_INLINE
> -#  define _EXTERN_INLINE extern __inline
> -# endif
> -
> -
> -_EXTERN_INLINE unsigned char
> +static __inline unsigned char
>  inb (unsigned short int port)
>  {
>    unsigned char _v;
> ...
>
> Using 'extern __inline' without optimization in --std=gnu89 would lead to
> the compiler using an 'extern' reference rather than emitting a static
> version,

This seems to be the original reason for the optimisation requirement.
The manual says [0]:

  GCC does not inline any functions when not optimizing unless you
  specify the ‘always_inline’ attribute for the function [...]

  [...]

  If you specify both inline and extern in the function definition, then
  the definition is used only for inlining.  In no case is the function
  compiled on its own, not even if you refer to its address explicitly.
  Such an address becomes an external reference, as if you had only
  declared the function, and had not defined it.

  This combination of inline and extern has almost the effect of a
  macro. [...]

  0: https://gcc.gnu.org/onlinedocs/gcc/Inline.html

Thus, using "extern inline" but not enabling optimisations (and not
providing a separate definition in some other object) would have
produced a linker error.

> the 'static __inline' variant works as intended in both gnu
> and standard c99.

That "__inline" keyword (yes, it's a keyword, regardless of eponymous
macros) is odd.  Apparently an old non-standard import from MSVC.

Are standard/newer keywords (inline/__inline__) not used for reasons of
backward compatibility (with old compiler or C language versions)?

Re: outb(2): terminology correction

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

Hi astian,

> Date: 2026-09-12 21:58:26+0000
> From: astian <astian@memeware.net>
>
[...]
> >> Arnd, should we remove the paragraph entirely?  Or is there any obscure
> >> reason why optimizations are required?
> >
> > Or maybe those assembly instructions are what causes the linker issues?
> > If so, we should probably say something about that.
> 
> I had a closer look and I now think that's not the case.  These
> instructions work fine even if the function is not inlined.  See more
> below.

Thanks!

> On 11 Sep 2026 14:20 +0200, Arnd Bergmann wrote:
[...]
> > Using 'extern __inline' without optimization in --std=gnu89 would lead to
> > the compiler using an 'extern' reference rather than emitting a static
> > version,
> 
> This seems to be the original reason for the optimisation requirement.

Agree.

> The manual says [0]:
> 
>   GCC does not inline any functions when not optimizing unless you
>   specify the ‘always_inline’ attribute for the function [...]
> 
>   [...]
> 
>   If you specify both inline and extern in the function definition, then
>   the definition is used only for inlining.  In no case is the function
>   compiled on its own, not even if you refer to its address explicitly.
>   Such an address becomes an external reference, as if you had only
>   declared the function, and had not defined it.
> 
>   This combination of inline and extern has almost the effect of a
>   macro. [...]
> 
>   0: https://gcc.gnu.org/onlinedocs/gcc/Inline.html
> 
> Thus, using "extern inline" but not enabling optimisations (and not
> providing a separate definition in some other object) would have
> produced a linker error.

Indeed.

> > the 'static __inline' variant works as intended in both gnu
> > and standard c99.
> 
> That "__inline" keyword (yes, it's a keyword, regardless of eponymous
> macros) is odd.  Apparently an old non-standard import from MSVC.
> 
> Are standard/newer keywords (inline/__inline__) not used for reasons of
> backward compatibility (with old compiler or C language versions)?

Yes, glibc needs to be compatible with C89, which doesn't have 'inline'.
Since users of C89 could be defining 'inline' for anything, glibc has to
use something in the implementation namespace.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]