public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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