From: Chris Wedgwood <cw@f00f.org>
To: Andrew Morton <akpm@zip.com.au>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
"David S. Miller" <davem@redhat.com>,
vandrove@vc.cvut.cz, torvalds@transmeta.com,
garzik@havoc.gtf.org, linux-kernel@vger.kernel.org,
paulus@samba.org, davidm@hpl.hp.com, ralf@gnu.org
Subject: Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does
Date: Fri, 1 Feb 2002 23:30:20 -0800 [thread overview]
Message-ID: <20020202073020.GA7014@tapu.f00f.org> (raw)
In-Reply-To: <20020131.145904.41634460.davem@redhat.com> <E16WQYs-0003Ux-00@the-village.bc.nu> <20020202021242.GA6770@tapu.f00f.org> <3C5B56A4.B762948F@zip.com.au>
In-Reply-To: <3C5B56A4.B762948F@zip.com.au>
On Fri, Feb 01, 2002 at 07:01:56PM -0800, Andrew Morton wrote:
We can. Graham Stoney had all this going against 2.2. See
http://www.google.com/search?q=stoney+ffunction-sections&hl=en&start=10&sa=N
http://www.cs.helsinki.fi/linux/linux-kernel/Year-2000/2000-29/0415.html
This puts every function it's own section. That seems not only
cumbersome to me, but also a little complex. That said, it may be a
good way if run every now and then to detect when cruft starts to
accumulate for any given .config and allow people to tweak things for
smaller kernels.
Is there no way to write something like:
--snip-- foo.c --snip--
void
blem()
{
}
void
bar()
{
blem();
return 0;
}
int foo()
{
return 1;
}
int main(...)
{
return foo();
}
--snip-- foo.c --snip--
compile and link it, have the linker know main or some part of crt0 is
special, build a graph of the final ELF object, see that bar and blem
are not connected to 'main' and discard them?
I'm pretty sure (but not 100% certain) that oher compilers can do
this, maybe someone can test on other platforms?
A really smart linker (if given enough compiler help) could build a
directional graph and still remove this code even if blem called foo.
Perhaps I'm making something that's extremely complex sound simple,
but it doesn't seem to me that this should be that complex... maybe
someone more farmiliar with binutils and/or gcc can comment and tell
me why I'm being a fool :)
The kernel doesn't link when you compile with -fno-inline because
of all the `extern inline' qualifiers. These need to be converted
to `static inline'. Jim Houston has a script which does this.
Semantically, in gcc land, someone explain the difference between:
inline
extern inline
static inline
please?
My tests seem to indicte:
inline creates an non-inline functions. Simple tests failed to have
this function inlined at all
static inline and extern inline functions can and will be inlined depending
on optimization level
extern inline doesn't product a non-inlined function (even if it is
referenced) and hence barfs if you don't compile with optimisations
for my simple test
Now, I wonder
why 'inline' for me, never inlines?
is there a way to force inlining of a function?
are non-inlined functions ever called when optimizations are
enabled?
Thanks,
--cw
next prev parent reply other threads:[~2002-02-02 7:32 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-31 20:27 crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does not Petr Vandrovec
2002-01-31 20:31 ` Jeff Garzik
2002-01-31 22:53 ` [PATCH] " Petr Vandrovec
2002-01-31 22:59 ` David S. Miller
2002-01-31 23:08 ` Jeff Garzik
2002-01-31 23:43 ` David Lang
2002-01-31 23:24 ` [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does Alan Cox
2002-01-31 23:21 ` Arnaldo Carvalho de Melo
2002-02-02 16:32 ` Denis Vlasenko
2002-02-02 12:57 ` Jens Axboe
2002-02-02 13:16 ` arjan
2002-02-02 13:52 ` Jens Axboe
2002-02-03 11:37 ` David Woodhouse
2002-01-31 23:43 ` Jeff Garzik
2002-01-31 23:45 ` David S. Miller
2002-02-01 0:32 ` Alan Cox
2002-02-01 10:07 ` Horst von Brand
2002-02-01 10:28 ` Keith Owens
2002-02-01 11:03 ` David S. Miller
2002-02-01 11:25 ` Keith Owens
2002-02-01 14:56 ` Jeff Garzik
2002-02-01 8:14 ` David Woodhouse
2002-02-02 2:12 ` Chris Wedgwood
2002-02-02 3:01 ` Andrew Morton
2002-02-02 7:30 ` Chris Wedgwood [this message]
2002-02-02 7:42 ` Daniel Jacobowitz
2002-02-02 8:08 ` Jeff Garzik
2002-02-02 19:20 ` Daniel Jacobowitz
2002-02-02 8:06 ` Jeff Garzik
2002-02-02 8:08 ` Keith Owens
2002-02-02 8:40 ` David Woodhouse
2002-02-02 8:59 ` Keith Owens
2002-02-02 9:14 ` David Woodhouse
2002-02-03 4:14 ` Eric W. Biederman
2002-02-03 7:01 ` Ralf Baechle
2002-02-03 9:13 ` Chris Wedgwood
2002-02-03 12:16 ` David Woodhouse
2002-02-03 12:33 ` Chris Wedgwood
2002-02-03 12:47 ` David Woodhouse
2002-02-03 13:40 ` Alan Cox
[not found] <20020131.162549.74750188.davem@redhat.com>
2002-02-01 0:42 ` Alan Cox
2002-02-01 0:30 ` David S. Miller
2002-02-01 3:46 ` Jeff Garzik
2002-02-01 4:25 ` David S. Miller
2002-02-01 4:48 ` Jeff Garzik
2002-02-01 5:59 ` David S. Miller
2002-02-01 5:10 ` Keith Owens
2002-02-01 5:12 ` Jeff Garzik
2002-02-01 5:18 ` Keith Owens
2002-02-01 13:42 ` Horst von Brand
2002-02-03 23:34 ` Keith Owens
2002-02-04 20:14 ` Horst von Brand
2002-02-01 6:01 ` David S. Miller
2002-02-01 6:11 ` Keith Owens
2002-02-01 6:26 ` David S. Miller
2002-02-01 6:43 ` Keith Owens
2002-02-01 15:03 ` Alan Cox
2002-02-01 14:55 ` Jeff Garzik
2002-02-01 15:12 ` Petr Vandrovec
2002-02-01 16:08 ` David Woodhouse
2002-02-04 13:24 ` Horst von Brand
2002-02-05 7:51 ` Jeff Garzik
2002-02-01 4:18 ` H. Peter Anvin
2002-02-01 4:35 ` Jeff Garzik
2002-02-01 15:19 ` Alan Cox
2002-02-01 19:37 ` Rob Landley
2002-02-01 19:50 ` Jeff Garzik
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=20020202073020.GA7014@tapu.f00f.org \
--to=cw@f00f.org \
--cc=akpm@zip.com.au \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@redhat.com \
--cc=davidm@hpl.hp.com \
--cc=garzik@havoc.gtf.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=ralf@gnu.org \
--cc=torvalds@transmeta.com \
--cc=vandrove@vc.cvut.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox