gcc 3.x, -ansi and "static inline"

gcc 3.x, -ansi and "static inline"

[Jun Sun]

We are trying to build userland apps with the newer kernel headers.
Unexpected problems occur with the "static inline" declaration
when "-ansi" option is used.

Anybody else is having the problem?

Also, what are the reasons for us to switch to "static inline" in the
kernel header?

Here is an example I am talking about:

In 2.4.2, we have in bitops.h:

extern __inline__ unsigned long ffz(unsigned long word)

In 2.4.17, we have instead:

static inline unsigned long ffz(unsigned long word)

This problem seems only happening with gcc 3.x.  I start to wonder
whether we should fix kernel header.  In some case, the fix seems
to be not exposing to userland (by #ifdef __KERNEL__).  In others,
the fix might be using __inline__.  

However, I really like to know what was the original motivation
to do such a change.

BTW, the inclusion of "mipsregs.h" file in bitops.h seems unnecessary
and caused a bunch of similar errors.

Jun

Re: gcc 3.x, -ansi and "static inline"

[Geert Uytterhoeven]

On Fri, 1 Feb 2002, Jun Sun wrote:
> We are trying to build userland apps with the newer kernel headers.
> Unexpected problems occur with the "static inline" declaration
> when "-ansi" option is used.
> 
> Anybody else is having the problem?
> 
> Also, what are the reasons for us to switch to "static inline" in the
> kernel header?
>
> Here is an example I am talking about:
> 
> In 2.4.2, we have in bitops.h:
> 
> extern __inline__ unsigned long ffz(unsigned long word)
> 
> In 2.4.17, we have instead:
> 
> static inline unsigned long ffz(unsigned long word)
> 
> This problem seems only happening with gcc 3.x.  I start to wonder
> whether we should fix kernel header.  In some case, the fix seems
> to be not exposing to userland (by #ifdef __KERNEL__).  In others,
> the fix might be using __inline__.  

Yes, #ifdef __KERNEL__ is the right fix.

> However, I really like to know what was the original motivation
> to do such a change.

See linux-kernel

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: gcc 3.x, -ansi and "static inline"

[Ralf Baechle]

On Fri, Feb 01, 2002 at 11:52:06AM -0800, Jun Sun wrote:

> BTW, the inclusion of "mipsregs.h" file in bitops.h seems unnecessary
> and caused a bunch of similar errors.

Indeed, it was pointless and I therefore removed it.

  Ralf

Re: gcc 3.x, -ansi and "static inline"

[Jun Sun]

Ralf Baechle wrote:
> 
> On Fri, Feb 01, 2002 at 11:52:06AM -0800, Jun Sun wrote:
> 
> > BTW, the inclusion of "mipsregs.h" file in bitops.h seems unnecessary
> > and caused a bunch of similar errors.
> 
> Indeed, it was pointless and I therefore removed it.
> 

What about ffz()?  We can do:

diff -Nru include/asm-mips/bitops.h.orig include/asm-mips/bitops.h
--- include/asm-mips/bitops.h.orig      Mon Feb  4 11:07:31 2002
+++ include/asm-mips/bitops.h   Mon Feb  4 11:21:14 2002
@@ -675,7 +675,7 @@
  *
  * Undefined if no zero exists, so code should check against ~0UL first.
  */
-static inline unsigned long ffz(unsigned long word)
+static __inline__ unsigned long ffz(unsigned long word)
 {
        int b = 0, s;
 

or 

diff -Nru include/asm-mips/bitops.h.orig include/asm-mips/bitops.h
--- include/asm-mips/bitops.h.orig      Mon Feb  4 11:07:31 2002
+++ include/asm-mips/bitops.h   Mon Feb  4 11:27:55 2002
@@ -669,6 +669,8 @@
 
 #endif /* !(__MIPSEB__) */
 
+#ifdef __KERNEL__
+
 /*
  * ffz - find first zero in word.
  * @word: The word to search
@@ -689,8 +691,6 @@
        return b;
 }
 
-
-#ifdef __KERNEL__
 
 /**
  * ffs - find first bit set


Jun

Re: gcc 3.x, -ansi and "static inline"

[Ralf Baechle]

On Mon, Feb 04, 2002 at 11:28:16AM -0800, Jun Sun wrote:

> > On Fri, Feb 01, 2002 at 11:52:06AM -0800, Jun Sun wrote:
> > 
> > > BTW, the inclusion of "mipsregs.h" file in bitops.h seems unnecessary
> > > and caused a bunch of similar errors.
> > 
> > Indeed, it was pointless and I therefore removed it.
> 
> What about ffz()?  We can do:

Including kernel header files into user code is the actual bug but if
you think fixing that isn't an option I can certainly so a
s/inline/__inline__/

  Ralf

Re: gcc 3.x, -ansi and "static inline"

[Jun Sun]

Ralf Baechle wrote:
> 
> On Mon, Feb 04, 2002 at 11:28:16AM -0800, Jun Sun wrote:
> 
> > > On Fri, Feb 01, 2002 at 11:52:06AM -0800, Jun Sun wrote:
> > >
> > > > BTW, the inclusion of "mipsregs.h" file in bitops.h seems unnecessary
> > > > and caused a bunch of similar errors.
> > >
> > > Indeed, it was pointless and I therefore removed it.
> >
> > What about ffz()?  We can do:
> 
> Including kernel header files into user code is the actual bug

In theory, yes.  In practice, kernel head is all a big mesh where we don't
have a clear division as which part can go to userland and which part can't.

The inline function makes mesh even meshier.

> but if
> you think fixing that isn't an option I can certainly so a
> s/inline/__inline__/
> 

I think this is the case.  See the inclusion chain below.  BTW, the app is
libcap.

In file included from
/opt/hardhat/devkit/mips/sb1_fp_be/target/usr/include/linux/fs.h:26,
                 from
/opt/hardhat/devkit/mips/sb1_fp_be/target/usr/include/linux/capability.h:17,
                 from
/var/tmp/BUILD/libcap-1.10.orig/libcap/include/sys/capability.h:24,
                 from libcap.h:19,
                 from cap_alloc.c:12:
/opt/hardhat/devkit/mips/sb1_fp_be/target/usr/include/asm/bitops.h:678: syntax
error before "unsigned"


Jun

Re: gcc 3.x, -ansi and "static inline"

[Ralf Baechle]

On Mon, Feb 04, 2002 at 02:56:43PM -0800, Jun Sun wrote:

> In theory, yes.  In practice, kernel head is all a big mesh where we don't
> have a clear division as which part can go to userland and which part can't.

The answer is already l-k faq probably - copy the kernel header to
userspace and hack it into your favorite shape.  I'm not a fan of this
policy but ...

  Ralf