From: Adrian Bunk <bunk@kernel.org>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Jie Zhang <jzhang.linux@gmail.com>,
bryan.wu@analog.com, linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] blackfin: "extern inline" -> "static inline"
Date: Thu, 25 Oct 2007 22:46:31 +0200 [thread overview]
Message-ID: <20071025204630.GV30533@stusta.de> (raw)
In-Reply-To: <8bd0f97a0710251320m3490c53dpe85656a939e8536e@mail.gmail.com>
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
prev parent reply other threads:[~2007-10-25 20:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-24 16:26 [2.6 patch] blackfin: "extern inline" -> "static inline" Adrian Bunk
2007-10-25 2:47 ` Jie Zhang
2007-10-25 3:00 ` Mike Frysinger
2007-10-25 3:06 ` H. Peter Anvin
2007-10-25 3:17 ` Mike Frysinger
2007-10-25 15:05 ` Adrian Bunk
2007-10-25 16:16 ` Mike Frysinger
2007-10-25 16:53 ` Adrian Bunk
2007-10-25 20:07 ` Mike Frysinger
2007-10-25 20:18 ` Adrian Bunk
2007-10-25 20:20 ` Mike Frysinger
2007-10-25 20:28 ` H. Peter Anvin
2007-10-25 20:45 ` Mike Frysinger
2007-10-25 20:53 ` H. Peter Anvin
2007-10-25 20:47 ` Adrian Bunk
2007-10-25 20:54 ` H. Peter Anvin
2007-10-25 20:46 ` Adrian Bunk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071025204630.GV30533@stusta.de \
--to=bunk@kernel.org \
--cc=bryan.wu@analog.com \
--cc=hpa@zytor.com \
--cc=jzhang.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vapier.adi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.