Guidance please: static or extern __inline__

Guidance please: static or extern __inline__

[Kean Johnston]

Hi everyone,

I've run into a little SNAFU with my porting work. In my
fixincludes changes I changed all forms in the header files
of (using stat as an example):
   static int
   stat(const char *__p, stat_t *__s)
   {
     return _xstat(_STAT_VER, __p, __s);
   }

to:
   extern int stat (const char *__p, stat_t *__s);
   extern __inline__ int
   stat(const char *__p, stat_t *__s)
   {
     return _xstat(_STAT_VER, __p, __s);
   }

 From reading teh docs it seems like 'extern __inline__' was
the way to go for this type of header file trickery. However,
it caused a problem bootstrapping the compiler, becuase the
first stage doesn't have -O, so any calls to stat() actually
go to the library routine called stat(), which is an old,
deprecated stat that can't deal with, say, 32-bit inodes or
uid_t's etc, and various programs like fixincludes then
fail to stat files.

If things are compiled with -O, everything works fine,
becuase _xstat, which is what I really want, is called. If
I change the extern __inline__ to static __inline__, it
works correctly, even without optimization.

However, I *think* I like the semantics of 'extern inline'
better: use the inline version for the most part but if,
for example, you take the address of the function, use the
actual symbol stat(). But I see that most other fixincs
use static inline.

So my question is in two parts I guess:
a) Which is the better thing to use in a header file for
    this type of function mapping? static or extern inline?
b) If its extern inline, is there a way to force the inline
    expansion even when not using -O (and without command
    line options). I wouldn't want users to get nasty
    surprises if they just used 'gcc -o foo foo.c'.

Any advice and guidance greatly appreciated.

Kean

Re: Guidance please: static or extern __inline__

[Gabriel Dos Reis]

Kean Johnston <jkj@sco.com> writes:

[...]

| However, I *think* I like the semantics of 'extern inline'
| better: use the inline version for the most part but if,
| for example, you take the address of the function, use the
| actual symbol stat(). But I see that most other fixincs
| use static inline.

I've long come to the conclulsion that "static inline" is the most
palatable form of the whole thingy -- its semantics does not depend on
optimization level.  It is also the form that suits needs for people
who need to write C++ codes that use or interface with C codes.

-- Gaby

Re: Guidance please: static or extern __inline__

[Kean Johnston]

> I've long come to the conclulsion that "static inline" is the most
> palatable form of the whole thingy -- its semantics does not depend on
> optimization level.  It is also the form that suits needs for people
> who need to write C++ codes that use or interface with C codes.
Thanks for the advice Gaby. I'll switch from extern inline
to static inline.

Kean

Re: Guidance please: static or extern __inline__

[Daniel Jacobowitz]

On Thu, Jul 28, 2005 at 09:12:21AM -0700, Kean Johnston wrote:
> to:
>   extern int stat (const char *__p, stat_t *__s);
>   extern __inline__ int
>   stat(const char *__p, stat_t *__s)
>   {
>     return _xstat(_STAT_VER, __p, __s);
>   }

...

> From reading teh docs it seems like 'extern __inline__' was
> the way to go for this type of header file trickery. However,
> it caused a problem bootstrapping the compiler, becuase the
> first stage doesn't have -O, so any calls to stat() actually
> go to the library routine called stat(), which is an old,
> deprecated stat that can't deal with, say, 32-bit inodes or
> uid_t's etc, and various programs like fixincludes then
> fail to stat files.

...

> However, I *think* I like the semantics of 'extern inline'
> better: use the inline version for the most part but if,
> for example, you take the address of the function, use the
> actual symbol stat(). But I see that most other fixincs
> use static inline.

Huh?  This paragraph conflicts with the previous one I quoted.  You
don't want extern inline, because you don't want the symbol stat() to
be called - that's your whole problem.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Guidance please: static or extern __inline__

[Kean Johnston]

>>However, I *think* I like the semantics of 'extern inline'
>>better: use the inline version for the most part but if,
>>for example, you take the address of the function, use the
>>actual symbol stat(). But I see that most other fixincs
>>use static inline.
> 
> 
> Huh?  This paragraph conflicts with the previous one I quoted.  You
> don't want extern inline, because you don't want the symbol stat() to
> be called - that's your whole problem.

Maybe I expressed myself unclearly. I also may have read the
docs wrong. But this is how I understand it:

extern void foo (void);
extern __inline__ void foo (void) {
   some_other_foo();
}

typedef void (*retfn_t)(void);

retfn_t bar (void)
{
   foo();         /* Really calls some_other_foo(); */
   return foo;    /* Returns extern reference to library func foo() */
}

If you compile the above without -O, you only get an UNDEF
for foo in the object file. If you compile it with -O, you
get the UNDEF for both foo and some_other_foo. If you change
extern __inline__ to static __inline__ and remove the first
decl, you only get an UNDEF for some_other_foo.

I thought that the -O case with extern inline was the most
correct. Say for example I have foo() in a library. It's
declared as a weak symbol for __foo. A very common case
with libc functions. A program can legitimately expect to
call foo(), get whatever the header file gives it (for
example, the header could "#define foo some_other_foo").
The same program may also want to return a function pointer
to foo(), and possibly even over-ride the weak library version
with a foo() of their own. The static inline case foils
all of that. The docs hint that 'extern inline' should behave
similarly to a macro, and it does, but only in the -O case.

Gaby pointed out that static inline is the most porttable
and doesn't depend on optimization, so I will go with that.
However, I think it is a mistake (albeit an intentional
one, the docs say that too) that extern inline behaves
differently with -O. I beleive that Gaby's concerns about
intefacing C++ code with C code should not be affected by
extern inline, but I bow to his superior knowledge.

FWIW, compiling with g++, with or without -O, creates
an UNDEF for some_other_foo, and a WEAK for foo. The
only other compiler I have access to, the USL compiler,
behaves the same way with or without -O, and creates
an UNDEF for some_other_foo, and a GLOB for foo. Go
figure.

For the particular problem I am having, I can live with
using static inline, but I *do* think that extern inline
should behave more like a macro in C mode, even without
-O.

Kean

Re: Guidance please: static or extern __inline__

[Daniel Jacobowitz]

On Thu, Jul 28, 2005 at 11:31:55AM -0700, Kean Johnston wrote:
> >>However, I *think* I like the semantics of 'extern inline'
> >>better: use the inline version for the most part but if,
> >>for example, you take the address of the function, use the
> >>actual symbol stat(). But I see that most other fixincs
> >>use static inline.
> >
> >
> >Huh?  This paragraph conflicts with the previous one I quoted.  You
> >don't want extern inline, because you don't want the symbol stat() to
> >be called - that's your whole problem.
> 
> Maybe I expressed myself unclearly. I also may have read the
> docs wrong. But this is how I understand it:
> 
> extern void foo (void);
> extern __inline__ void foo (void) {
>   some_other_foo();
> }
> 
> typedef void (*retfn_t)(void);
> 
> retfn_t bar (void)
> {
>   foo();         /* Really calls some_other_foo(); */
>   return foo;    /* Returns extern reference to library func foo() */
> }
> 
> If you compile the above without -O, you only get an UNDEF
> for foo in the object file. If you compile it with -O, you
> get the UNDEF for both foo and some_other_foo. If you change
> extern __inline__ to static __inline__ and remove the first
> decl, you only get an UNDEF for some_other_foo.

Which is what you want.  Your symbol stat() is a legacy interface that
should not be used by new programs.  Any alternative that allows you to
generate an undefined reference to stat is a bad alternative, because
it will call the legacy function from new code.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Guidance please: static or extern __inline__

[Mike Stump]

On Jul 28, 2005, at 9:12 AM, Kean Johnston wrote:
>   extern int stat (const char *__p, stat_t *__s);
>   extern __inline__ int
>   stat(const char *__p, stat_t *__s)
>   {
>     return _xstat(_STAT_VER, __p, __s);
>   }
>

> However, it caused a problem bootstrapping the compiler, becuase  
> the first stage doesn't have -O, so any calls to stat() actually go  
> to the library routine called stat(), which is an old, deprecated  
> stat that can't deal

[ cough ] "always_inline" [ cough ]

Re: Guidance please: static or extern __inline__

[Kean Johnston]

> [ cough ] "always_inline" [ cough ]
HA!

I *knew* there was a solution. Thank you Mike.

So now I guess the question remains, for the cases where
you want a function to behave differently depending on
pre-processor conditionals, whats the best way of doing
it? The particularly interesting case is with LFS stuff:

extern int open (const char *, int, int);	/* Legacy */
extern int __open (const char *, int, int);	/* New */
extern int open32 (const char *, int, int);	/* New LFS */
extern int open64 (const char *, int, int);	/* New LFS */

#if _FILE_OFFSET_BITS - 0 == 32
#define open open32
#elif _FILE_OFFSET_BITS - 0 == 64
#define open open64
#else
#define open __open
#endif

Wreaks havoc with libstdc++ and libjava, where class
members are called 'open'. I would ideally want those calls
defined in terms of inline, and leave the pre-processor
out of it. For argument's sake, lets assume open wasn't
actualy variadic and that it was declared as above. Would
the best thing to have in the header file be:

#if _FILE_OFFSET_BITS - 0 == 32
static __inline__ int open (const char *__1, int __2, int __3)
{
   return open32(__1, __2, __3);
}
#endif

-or-

#if _FILE_OFFSET_BITS - 0 == 32
extern __inline__ __attribute__ ((__always_inline__))
int open (const char *__1, int __2, int __3)
{
   return open32(__1, __2, __3);
}
#endif

I fully understand Daniel's point about why you *dont* want
&open to really return the address of the old open, but you
may also want &open to be consistent across different
modules. With the static inline case, they won't be. The case
where that sort of shenanigans is refering to old API's is
of course the worst case. However, for other simpler cases,
lets say, min or max, you may well have a version in libc,
for linkage purposes, but under normal circumstances you
would like it to be inlined. &min would be the same always,
but in cases where you are not taking the address of the
function, and are just using it, you want the quicker, inlined
version to save on a call to libc.

I'm trying to solve a problem not create one, and I get the
feeling that using static inline will solve more problems,
but I am at war with the pedant in me that says the extern
inline case may be more "purely correct".

Kean

Re: Guidance please: static or extern __inline__

[Gabriel Dos Reis]

Kean Johnston <jkj@sco.com> writes:

| > [ cough ] "always_inline" [ cough ]
| HA!
| 
| I *knew* there was a solution. Thank you Mike.
| 
| So now I guess the question remains, for the cases where
| you want a function to behave differently depending on
| pre-processor conditionals, whats the best way of doing
| it? The particularly interesting case is with LFS stuff:
| 
| extern int open (const char *, int, int);	/* Legacy */
| extern int __open (const char *, int, int);	/* New */
| extern int open32 (const char *, int, int);	/* New LFS */
| extern int open64 (const char *, int, int);	/* New LFS */
| 
| #if _FILE_OFFSET_BITS - 0 == 32
| #define open open32
| #elif _FILE_OFFSET_BITS - 0 == 64
| #define open open64
| #else
| #define open __open
| #endif
| 
| Wreaks havoc with libstdc++ and libjava, where class
| members are called 'open'. I would ideally want those calls

yes, you really don't want tp play Cpp games there :-)

| defined in terms of inline, and leave the pre-processor
| out of it. For argument's sake, lets assume open wasn't
| actualy variadic and that it was declared as above. Would
| the best thing to have in the header file be:
| 
| #if _FILE_OFFSET_BITS - 0 == 32
| static __inline__ int open (const char *__1, int __2, int __3)
| {
|    return open32(__1, __2, __3);
| }
| #endif
| 
| -or-
| 
| #if _FILE_OFFSET_BITS - 0 == 32
| extern __inline__ __attribute__ ((__always_inline__))
| int open (const char *__1, int __2, int __3)
| {
|    return open32(__1, __2, __3);
| }
| #endif
| 
| I fully understand Daniel's point about why you *dont* want
| &open to really return the address of the old open, but you
| may also want &open to be consistent across different
| modules. With the static inline case, they won't be. The case
| where that sort of shenanigans is refering to old API's is
| of course the worst case. However, for other simpler cases,
| lets say, min or max, you may well have a version in libc,
| for linkage purposes, but under normal circumstances you
| would like it to be inlined. &min would be the same always,
| but in cases where you are not taking the address of the
| function, and are just using it, you want the quicker, inlined
| version to save on a call to libc.

So, can I summarize your question as a way of trying to make "open"
and alias for open32 or open63 and not having to get into the trap of
different function address?  If yes, does glibc's weak_alias would
work for you without creating new problems?

| I'm trying to solve a problem not create one, and I get the
| feeling that using static inline will solve more problems,
| but I am at war with the pedant in me that says the extern
| inline case may be more "purely correct".

I can understand that :-)

-- Gaby

Re: Guidance please: static or extern __inline__

[Kean Johnston]

> So, can I summarize your question as a way of trying to make "open"
> and alias for open32 or open63 and not having to get into the trap of
> different function address?  If yes, does glibc's weak_alias would
> work for you without creating new problems?
Yeah thats pretty much it, but I dont think weak aliasing
is the trick (if I understand what you mean by weak aliasing --
if you mean something other than #pragma weak then ignore the
next paragraph).

The problem with weak symbols is that they are only really
useful at link-edit time, and then only if you want to override
the symbol with one of your own. Considering that you offered
weak_alias as a solution, I am guessing that you are not talking
about simple weak symbols. I need this to be resolved at compile
time (so that we call the right version of open, stat, whatever)
without getting into the CPP namespace quagmire. But you said
"glibc's weak_alias" ... I think that puts me out of the running
considering this is a SCO platform :( This has to inteface
with our libc (this wont be the first or last time I have wished
I could use glibc).

I think for right now, I am going to go with the extern
inline and always_inline approach, and test the hell out
of the beast, with as much code as I can (testsuites and
stuff like php, apache, postgresql, Xorg, KDE, Xalan, Xerces).
If those all work I will consider my work done :) If it
doesn't work its trivial to adjust the fixincludes stuff
to use static inline, and I will do so before I submit my
patches.

Kean

Re: Guidance please: static or extern __inline__

[Mike Stump]

On Jul 28, 2005, at 12:42 PM, Kean Johnston wrote:
>> [ cough ] "always_inline" [ cough ]
> HA!
>
> I *knew* there was a solution. Thank you Mike.
>
> So now I guess the question remains, for the cases where
> you want a function to behave differently depending on
> pre-processor conditionals, whats the best way of doing
> it?

[ cough ]

#if _FILE_OFFSET_BITS - 0 == 32
  int open (const char *, int, int) asm ("open32");
#elif _FILE_OFFSET_BITS - 0 == 64
  int open (const char *, int, int) asm ("open64");
#else
  int open (const char *, int, int) asm ("__open");
#endif

[ cough ]

Re: Guidance please: static or extern __inline__

[Kean Johnston]

> [ cough ]
> 
> #if _FILE_OFFSET_BITS - 0 == 32
>  int open (const char *, int, int) asm ("open32");
> #elif _FILE_OFFSET_BITS - 0 == 64
>  int open (const char *, int, int) asm ("open64");
> #else
>  int open (const char *, int, int) asm ("__open");
> #endif

That's a pretty neat trick. I dont suppose I could
trouble you to give me the voodoo required for
inserting an extra pushl before the call could I?

PS this trick you described here is great for variadic
functions like open and ioctl. It is the ioctl case
where I need to push an extra arg and then call a
fn called _xioctl. Your assistance would be very
much appreciated. Thanks Mike.

Kean

Re: Guidance please: static or extern __inline__

[Mike Stump]

On Friday, July 29, 2005, at 01:23 PM, Kean Johnston wrote:
>> [ cough ]
>> #if _FILE_OFFSET_BITS - 0 == 32
>>  int open (const char *, int, int) asm ("open32");
>> #elif _FILE_OFFSET_BITS - 0 == 64
>>  int open (const char *, int, int) asm ("open64");
>> #else
>>  int open (const char *, int, int) asm ("__open");
>> #endif
>
> That's a pretty neat trick.

I know, we've filed a patent for it, wait for it, no, wait, ok, just 
kidding...  :-)

> I dont suppose I could trouble you to give me the voodoo required for
> inserting an extra pushl before the call could I?

Not sure exactly what you want, but with the below I think it will be 
obvious how to do it.

void ioctl(int, unsigned long, char *) __attribute__((always_inline));
asm inline void ioctl(int fd, unsigned long m, char *buf) {
         movl    #42, 12($esp)
         movl    fd, 8($esp)
         movl    m, 4($esp)
         movl    buf, ($esp)
         call    _xioctl
         xorl    $eax, $eax
         leave
         ret
}

main() {
   ioctl (0, 0, "hi");
}

though, you may need nakky and to spell the inline slightly 
differently, the above uses CW style assembly.

Re: Guidance please: static or extern __inline__

[Kean Johnston]

>> That's a pretty neat trick.
> 
> 
> I know, we've filed a patent for it, wait for it, no, wait, ok, just 
> kidding...  :-)
Hehehehe :)

> 
>> I dont suppose I could trouble you to give me the voodoo required for
>> inserting an extra pushl before the call could I?
> 
> 
> Not sure exactly what you want, but with the below I think it will be 
> obvious how to do it.
> 
> void ioctl(int, unsigned long, char *) __attribute__((always_inline));
> asm inline void ioctl(int fd, unsigned long m, char *buf) {
>         movl    #42, 12($esp)
>         movl    fd, 8($esp)
>         movl    m, 4($esp)
>         movl    buf, ($esp)
>         call    _xioctl
>         xorl    $eax, $eax
>         leave
>         ret
> }
That does help with teh general mechanism. Unfortunately I can't
use inline, becuase ioctl is supposed to be declared as
int ioctl (int, int, ...);. I dont think you can have variadic
inline's can you?

This whole notion of fixing ABI issues in header files makes
my you-know-what's ache.  Of course the *rest* of the world
has decent symbol versioning, but some of us are left in the
approximate mid-90's :(

I think I may just cheat and declare ioctl incorrectly, and
put in the 3rd arg. I suspect that is the path of least
resistance, although I have no doubt it will break some
standard. But since I'm shooting for a working, real-world
compiler, I find myself strangely comfortable with the idea
of ignoring a miniscule subclause here and there in a
standard I'm not certifying to :)

Thanks for all your help tho. It's much appreciated.

Kean