[2.6 patch] blackfin: "extern inline" -> "static inline"

[2.6 patch] blackfin: "extern inline" -> "static inline"

[Adrian Bunk]

"extern inline" will have different semantics with gcc 4.3.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---

 include/asm-blackfin/string.h |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

f2a6901348a61a13fc19a01f5584406190302919 
diff --git a/include/asm-blackfin/string.h b/include/asm-blackfin/string.h
index e8ada91..e4703a7 100644
--- a/include/asm-blackfin/string.h
+++ b/include/asm-blackfin/string.h
@@ -4,7 +4,7 @@
 #ifdef __KERNEL__		/* only set these up for kernel code */
 
 #define __HAVE_ARCH_STRCPY
-extern inline char *strcpy(char *dest, const char *src)
+static inline char *strcpy(char *dest, const char *src)
 {
 	char *xdest = dest;
 	char temp = 0;
@@ -23,7 +23,7 @@ extern inline char *strcpy(char *dest, const char *src)
 }
 
 #define __HAVE_ARCH_STRNCPY
-extern inline char *strncpy(char *dest, const char *src, size_t n)
+static inline char *strncpy(char *dest, const char *src, size_t n)
 {
 	char *xdest = dest;
 	char temp = 0;
@@ -59,7 +59,7 @@ extern inline char *strncpy(char *dest, const char *src, size_t n)
 }
 
 #define __HAVE_ARCH_STRCMP
-extern inline int strcmp(const char *cs, const char *ct)
+static inline int strcmp(const char *cs, const char *ct)
 {
 	/* need to use int's here so the char's in the assembly don't get
 	 * sign extended incorrectly when we don't want them to be
@@ -86,7 +86,7 @@ extern inline int strcmp(const char *cs, const char *ct)
 }
 
 #define __HAVE_ARCH_STRNCMP
-extern inline int strncmp(const char *cs, const char *ct, size_t count)
+static inline int strncmp(const char *cs, const char *ct, size_t count)
 {
 	/* need to use int's here so the char's in the assembly don't get
 	 * sign extended incorrectly when we don't want them to be

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Jie Zhang]

On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> "extern inline" will have different semantics with gcc 4.3.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> --- a/include/asm-blackfin/string.h
> +++ b/include/asm-blackfin/string.h
> @@ -4,7 +4,7 @@
>  #ifdef __KERNEL__              /* only set these up for kernel code */
>
>  #define __HAVE_ARCH_STRCPY
> -extern inline char *strcpy(char *dest, const char *src)
> +static inline char *strcpy(char *dest, const char *src)
>  {
>         char *xdest = dest;
>         char temp = 0;

What if we compile it with gcc 4.1?


Jie

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Mike Frysinger]

On 10/24/07, Jie Zhang <jzhang.linux@gmail.com> wrote:
> On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> > "extern inline" will have different semantics with gcc 4.3.
> >
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> >
> > --- a/include/asm-blackfin/string.h
> > +++ b/include/asm-blackfin/string.h
> > @@ -4,7 +4,7 @@
> >  #ifdef __KERNEL__              /* only set these up for kernel code */
> >
> >  #define __HAVE_ARCH_STRCPY
> > -extern inline char *strcpy(char *dest, const char *src)
> > +static inline char *strcpy(char *dest, const char *src)
> >  {
> >         char *xdest = dest;
> >         char temp = 0;
>
> What if we compile it with gcc 4.1?

we'll have to either use the gcc attributes to force old inline
behavior or use the gcc flag to force it
-mike

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[H. Peter Anvin]

Mike Frysinger wrote:
> On 10/24/07, Jie Zhang <jzhang.linux@gmail.com> wrote:
>> On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
>>> "extern inline" will have different semantics with gcc 4.3.
>>>
>>> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>>>
>>> --- a/include/asm-blackfin/string.h
>>> +++ b/include/asm-blackfin/string.h
>>> @@ -4,7 +4,7 @@
>>>  #ifdef __KERNEL__              /* only set these up for kernel code */
>>>
>>>  #define __HAVE_ARCH_STRCPY
>>> -extern inline char *strcpy(char *dest, const char *src)
>>> +static inline char *strcpy(char *dest, const char *src)
>>>  {
>>>         char *xdest = dest;
>>>         char temp = 0;
>> What if we compile it with gcc 4.1?
> 
> we'll have to either use the gcc attributes to force old inline
> behavior or use the gcc flag to force it

We should probably have an extern_inline define then, assuming this is a 
function that does exist in a linkable version already -- otherwise 
"static inline" is correct.

	-hpa

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Mike Frysinger]

On 10/24/07, H. Peter Anvin <hpa@zytor.com> wrote:
> Mike Frysinger wrote:
> > On 10/24/07, Jie Zhang <jzhang.linux@gmail.com> wrote:
> >> On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> >>> "extern inline" will have different semantics with gcc 4.3.
> >>>
> >>> Signed-off-by: Adrian Bunk <bunk@kernel.org>
> >>>
> >>> --- a/include/asm-blackfin/string.h
> >>> +++ b/include/asm-blackfin/string.h
> >>> @@ -4,7 +4,7 @@
> >>>  #ifdef __KERNEL__              /* only set these up for kernel code */
> >>>
> >>>  #define __HAVE_ARCH_STRCPY
> >>> -extern inline char *strcpy(char *dest, const char *src)
> >>> +static inline char *strcpy(char *dest, const char *src)
> >>>  {
> >>>         char *xdest = dest;
> >>>         char temp = 0;
> >> What if we compile it with gcc 4.1?
> >
> > we'll have to either use the gcc attributes to force old inline
> > behavior or use the gcc flag to force it
>
> We should probably have an extern_inline define then, assuming this is a
> function that does exist in a linkable version already -- otherwise
> "static inline" is correct.

right, we do have string versions in arch/blackfin/lib/ and we do want
the "classical" gcc behavior here with "extern static".  an
extern_inline macro in compiler.h sounds good since
__attribute__((__gnu_inline__)) doesnt exist in gcc-3.4.x (the other
version that works for Blackfin other than gcc-4.1.x).

so i guess NACK this patch since we dont want "static inline" and we
dont yet support gcc-4.3 on Blackfin.
-mike

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Adrian Bunk]

On Wed, Oct 24, 2007 at 08:06:14PM -0700, H. Peter Anvin wrote:
> Mike Frysinger wrote:
>> On 10/24/07, Jie Zhang <jzhang.linux@gmail.com> wrote:
>>> On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
>>>> "extern inline" will have different semantics with gcc 4.3.
>>>>
>>>> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>>>>
>>>> --- a/include/asm-blackfin/string.h
>>>> +++ b/include/asm-blackfin/string.h
>>>> @@ -4,7 +4,7 @@
>>>>  #ifdef __KERNEL__              /* only set these up for kernel code */
>>>>
>>>>  #define __HAVE_ARCH_STRCPY
>>>> -extern inline char *strcpy(char *dest, const char *src)
>>>> +static inline char *strcpy(char *dest, const char *src)
>>>>  {
>>>>         char *xdest = dest;
>>>>         char temp = 0;
>>> What if we compile it with gcc 4.1?
>> we'll have to either use the gcc attributes to force old inline
>> behavior or use the gcc flag to force it
>
> We should probably have an extern_inline define then, assuming this is a 
> function that does exist in a linkable version already -- otherwise "static 
> inline" is correct.

Since we #define inline to be __attribute__((always_inline))
"extern inline" with the old semantics would only behave differently
if someone took the address of one of these string functions.

Does this happen anywhere in the blackfin port?

> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Mike Frysinger]

On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> On Wed, Oct 24, 2007 at 08:06:14PM -0700, H. Peter Anvin wrote:
> > Mike Frysinger wrote:
> >> we'll have to either use the gcc attributes to force old inline
> >> behavior or use the gcc flag to force it
> >
> > We should probably have an extern_inline define then, assuming this is a
> > function that does exist in a linkable version already -- otherwise "static
> > inline" is correct.
>
> Since we #define inline to be __attribute__((always_inline))
> "extern inline" with the old semantics would only behave differently
> if someone took the address of one of these string functions.

that isnt what we intended ;)

> Does this happen anywhere in the blackfin port?

gcc is also free to ignore the optimized inline in favor of an
external reference
-mike

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Adrian Bunk]

On Thu, Oct 25, 2007 at 12:16:40PM -0400, Mike Frysinger wrote:
> On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> > On Wed, Oct 24, 2007 at 08:06:14PM -0700, H. Peter Anvin wrote:
> > > Mike Frysinger wrote:
> > >> we'll have to either use the gcc attributes to force old inline
> > >> behavior or use the gcc flag to force it
> > >
> > > We should probably have an extern_inline define then, assuming this is a
> > > function that does exist in a linkable version already -- otherwise "static
> > > inline" is correct.
> >
> > Since we #define inline to be __attribute__((always_inline))
> > "extern inline" with the old semantics would only behave differently
> > if someone took the address of one of these string functions.
> 
> that isnt what we intended ;)
> 
> > Does this happen anywhere in the blackfin port?
> 
> gcc is also free to ignore the optimized inline in favor of an
> external reference

It is not since we #define inline to be __attribute__((always_inline)).

> -mike

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Mike Frysinger]

On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> On Thu, Oct 25, 2007 at 12:16:40PM -0400, Mike Frysinger wrote:
> > On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> > > On Wed, Oct 24, 2007 at 08:06:14PM -0700, H. Peter Anvin wrote:
> > > > Mike Frysinger wrote:
> > > >> we'll have to either use the gcc attributes to force old inline
> > > >> behavior or use the gcc flag to force it
> > > >
> > > > We should probably have an extern_inline define then, assuming this is a
> > > > function that does exist in a linkable version already -- otherwise "static
> > > > inline" is correct.
> > >
> > > Since we #define inline to be __attribute__((always_inline))
> > > "extern inline" with the old semantics would only behave differently
> > > if someone took the address of one of these string functions.
> >
> > that isnt what we intended ;)
> >
> > > Does this happen anywhere in the blackfin port?
> >
> > gcc is also free to ignore the optimized inline in favor of an
> > external reference
>
> It is not since we #define inline to be __attribute__((always_inline)).

as i said, that was not what we intended ... and actually,
always_inline does not mean always inline ... it is still possible to
get gcc to not inline things when building debug versions.
-mike

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Adrian Bunk]

On Thu, Oct 25, 2007 at 04:07:45PM -0400, Mike Frysinger wrote:
> On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> > On Thu, Oct 25, 2007 at 12:16:40PM -0400, Mike Frysinger wrote:
> > > On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> > > > On Wed, Oct 24, 2007 at 08:06:14PM -0700, H. Peter Anvin wrote:
> > > > > Mike Frysinger wrote:
> > > > >> we'll have to either use the gcc attributes to force old inline
> > > > >> behavior or use the gcc flag to force it
> > > > >
> > > > > We should probably have an extern_inline define then, assuming this is a
> > > > > function that does exist in a linkable version already -- otherwise "static
> > > > > inline" is correct.
> > > >
> > > > Since we #define inline to be __attribute__((always_inline))
> > > > "extern inline" with the old semantics would only behave differently
> > > > if someone took the address of one of these string functions.
> > >
> > > that isnt what we intended ;)
> > >
> > > > Does this happen anywhere in the blackfin port?
> > >
> > > gcc is also free to ignore the optimized inline in favor of an
> > > external reference
> >
> > It is not since we #define inline to be __attribute__((always_inline)).
> 
> as i said, that was not what we intended ... and actually,
> always_inline does not mean always inline ... it is still possible to
> get gcc to not inline things when building debug versions.

Do you have any example for your claim "to get gcc to not inline things 
when building debug versions"?

> -mike

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Mike Frysinger]

On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> On Thu, Oct 25, 2007 at 04:07:45PM -0400, Mike Frysinger wrote:
> > On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> > > On Thu, Oct 25, 2007 at 12:16:40PM -0400, Mike Frysinger wrote:
> > > > On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> > > > > On Wed, Oct 24, 2007 at 08:06:14PM -0700, H. Peter Anvin wrote:
> > > > > > Mike Frysinger wrote:
> > > > > >> we'll have to either use the gcc attributes to force old inline
> > > > > >> behavior or use the gcc flag to force it
> > > > > >
> > > > > > We should probably have an extern_inline define then, assuming this is a
> > > > > > function that does exist in a linkable version already -- otherwise "static
> > > > > > inline" is correct.
> > > > >
> > > > > Since we #define inline to be __attribute__((always_inline))
> > > > > "extern inline" with the old semantics would only behave differently
> > > > > if someone took the address of one of these string functions.
> > > >
> > > > that isnt what we intended ;)
> > > >
> > > > > Does this happen anywhere in the blackfin port?
> > > >
> > > > gcc is also free to ignore the optimized inline in favor of an
> > > > external reference
> > >
> > > It is not since we #define inline to be __attribute__((always_inline)).
> >
> > as i said, that was not what we intended ... and actually,
> > always_inline does not mean always inline ... it is still possible to
> > get gcc to not inline things when building debug versions.
>
> Do you have any example for your claim "to get gcc to not inline things
> when building debug versions"?

$ cat test.c
__attribute__((always_inline)) int foo(void) { return 0; }
int main(void){ return foo(); }
$ gcc -g test.c -o test
$ readelf -s test | grep FUNC | grep -v _
    61: 00000000004004b8    11 FUNC    GLOBAL DEFAULT   13 foo
    68: 00000000004004c3    11 FUNC    GLOBAL DEFAULT   13 main

looks pretty straightforward to me
-mike

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[H. Peter Anvin]

Mike Frysinger wrote:
>> Do you have any example for your claim "to get gcc to not inline things
>> when building debug versions"?
> 
> $ cat test.c
> __attribute__((always_inline)) int foo(void) { return 0; }
> int main(void){ return foo(); }
> $ gcc -g test.c -o test
> $ readelf -s test | grep FUNC | grep -v _
>     61: 00000000004004b8    11 FUNC    GLOBAL DEFAULT   13 foo
>     68: 00000000004004c3    11 FUNC    GLOBAL DEFAULT   13 main
> 
> looks pretty straightforward to me
> -mike

For "debug version" meaning -O0, this is true.

	-hpa

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Mike Frysinger]

On 10/25/07, H. Peter Anvin <hpa@zytor.com> wrote:
> Mike Frysinger wrote:
> >> Do you have any example for your claim "to get gcc to not inline things
> >> when building debug versions"?
> >
> > $ cat test.c
> > __attribute__((always_inline)) int foo(void) { return 0; }
> > int main(void){ return foo(); }
> > $ gcc -g test.c -o test
> > $ readelf -s test | grep FUNC | grep -v _
> >     61: 00000000004004b8    11 FUNC    GLOBAL DEFAULT   13 foo
> >     68: 00000000004004c3    11 FUNC    GLOBAL DEFAULT   13 main
> >
> > looks pretty straightforward to me
>
> For "debug version" meaning -O0, this is true.

which is what i meant, sorry for not being more clear

anyways, this is all moot ... we dont want "always inline" nor do we
want "static inline" for our string functions.  we want the classical
GNU meaning of "extern inline" which means we're going to either have
a Blackfin specific "extern_inline" define or we get one added to the
common compiler headers and use that.

Peter (or is it "H. Peter" ?): you going to post a patch or should i ?
-mike

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Adrian Bunk]

On Thu, Oct 25, 2007 at 04:20:20PM -0400, Mike Frysinger wrote:
> On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> > On Thu, Oct 25, 2007 at 04:07:45PM -0400, Mike Frysinger wrote:
> > > On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> > > > On Thu, Oct 25, 2007 at 12:16:40PM -0400, Mike Frysinger wrote:
> > > > > On 10/25/07, Adrian Bunk <bunk@kernel.org> wrote:
> > > > > > On Wed, Oct 24, 2007 at 08:06:14PM -0700, H. Peter Anvin wrote:
> > > > > > > Mike Frysinger wrote:
> > > > > > >> we'll have to either use the gcc attributes to force old inline
> > > > > > >> behavior or use the gcc flag to force it
> > > > > > >
> > > > > > > We should probably have an extern_inline define then, assuming this is a
> > > > > > > function that does exist in a linkable version already -- otherwise "static
> > > > > > > inline" is correct.
> > > > > >
> > > > > > Since we #define inline to be __attribute__((always_inline))
> > > > > > "extern inline" with the old semantics would only behave differently
> > > > > > if someone took the address of one of these string functions.
> > > > >
> > > > > that isnt what we intended ;)
> > > > >
> > > > > > Does this happen anywhere in the blackfin port?
> > > > >
> > > > > gcc is also free to ignore the optimized inline in favor of an
> > > > > external reference
> > > >
> > > > It is not since we #define inline to be __attribute__((always_inline)).
> > >
> > > as i said, that was not what we intended ... and actually,
> > > always_inline does not mean always inline ... it is still possible to
> > > get gcc to not inline things when building debug versions.
> >
> > Do you have any example for your claim "to get gcc to not inline things
> > when building debug versions"?
> 
> $ cat test.c
> __attribute__((always_inline)) int foo(void) { return 0; }
> int main(void){ return foo(); }
> $ gcc -g test.c -o test
> $ readelf -s test | grep FUNC | grep -v _
>     61: 00000000004004b8    11 FUNC    GLOBAL DEFAULT   13 foo
>     68: 00000000004004c3    11 FUNC    GLOBAL DEFAULT   13 main
> 
> looks pretty straightforward to me

That a function gets emitted for a non-static inline function is 
expected (and unrelated to the static inline cases).

But if you replace "__attribute__((always_inline))" with
"inline __attribute__((always_inline))" as we do in the kernel,
foo() is no longer called from main().

And if you make it "static inline __attribute__((always_inline))" (which 
is what "static inline" in the kernel expands to), there's no longer a 
function "foo" in the binary.

> -mike

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[Adrian Bunk]

On Thu, Oct 25, 2007 at 01:28:04PM -0700, H. Peter Anvin wrote:
> Mike Frysinger wrote:
>>> Do you have any example for your claim "to get gcc to not inline things
>>> when building debug versions"?
>> $ cat test.c
>> __attribute__((always_inline)) int foo(void) { return 0; }
>> int main(void){ return foo(); }
>> $ gcc -g test.c -o test
>> $ readelf -s test | grep FUNC | grep -v _
>>     61: 00000000004004b8    11 FUNC    GLOBAL DEFAULT   13 foo
>>     68: 00000000004004c3    11 FUNC    GLOBAL DEFAULT   13 main
>> looks pretty straightforward to me
>> -mike
>
> For "debug version" meaning -O0, this is true.

No, "inline __attribute__((always_inline))" works with -O0.

He gets a function emitted since his "foo" is not static.

> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[H. Peter Anvin]

Mike Frysinger wrote:
> On 10/25/07, H. Peter Anvin <hpa@zytor.com> wrote:
>> Mike Frysinger wrote:
>>>> Do you have any example for your claim "to get gcc to not inline things
>>>> when building debug versions"?
>>> $ cat test.c
>>> __attribute__((always_inline)) int foo(void) { return 0; }
>>> int main(void){ return foo(); }
>>> $ gcc -g test.c -o test
>>> $ readelf -s test | grep FUNC | grep -v _
>>>     61: 00000000004004b8    11 FUNC    GLOBAL DEFAULT   13 foo
>>>     68: 00000000004004c3    11 FUNC    GLOBAL DEFAULT   13 main
>>>
>>> looks pretty straightforward to me
>> For "debug version" meaning -O0, this is true.
> 
> which is what i meant, sorry for not being more clear
> 
> anyways, this is all moot ... we dont want "always inline" nor do we
> want "static inline" for our string functions.  we want the classical
> GNU meaning of "extern inline" which means we're going to either have
> a Blackfin specific "extern_inline" define or we get one added to the
> common compiler headers and use that.
> 
> Peter (or is it "H. Peter" ?): you going to post a patch or should i ?
> -mike

Just "Peter" is fine :)

Go right ahead.

	-hpa

Re: [2.6 patch] blackfin: "extern inline" -> "static inline"

[H. Peter Anvin]

Adrian Bunk wrote:
> On Thu, Oct 25, 2007 at 01:28:04PM -0700, H. Peter Anvin wrote:
>> Mike Frysinger wrote:
>>>> Do you have any example for your claim "to get gcc to not inline things
>>>> when building debug versions"?
>>> $ cat test.c
>>> __attribute__((always_inline)) int foo(void) { return 0; }
>>> int main(void){ return foo(); }
>>> $ gcc -g test.c -o test
>>> $ readelf -s test | grep FUNC | grep -v _
>>>     61: 00000000004004b8    11 FUNC    GLOBAL DEFAULT   13 foo
>>>     68: 00000000004004c3    11 FUNC    GLOBAL DEFAULT   13 main
>>> looks pretty straightforward to me
>>> -mike
>> For "debug version" meaning -O0, this is true.
> 
> No, "inline __attribute__((always_inline))" works with -O0.
> 
> He gets a function emitted since his "foo" is not static.
> 

Oh, right.

	-hpa