Re: outb(2): terminology correction

["astian" <astian@memeware.net>]

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)?