public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: Alex Bennee <alex@braddahead.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Why do some net drivers require __OPTIMIZE__?
Date: Tue, 7 Jan 2003 16:58:38 -0500	[thread overview]
Message-ID: <20030107215838.GA20046@nevyn.them.org> (raw)
In-Reply-To: <1041949988.21044.37.camel@cambridge.braddahead>

On Tue, Jan 07, 2003 at 02:33:07PM +0000, Alex Bennee wrote:
> On Mon, 2003-01-06 at 15:36, Alan Cox wrote:
> > > Does anybody know the history behind those lines? Do they serve any
> > > purpose now or in the past? Should I be nervous about compiling the
> > > kernel at a *lower* than normal optimization level? After all
> > > optimizations are generally processor specific and shouldn't affect the
> > > meaning of the C.
> > 
> > Some of our inline and asm blocks assume things like optimisation. Killing
> > that check and adding -finline-functions ought to be enough to get what
> > you expect.
> 
> It appears to go deeper than a few network drivers. Droping to -O0
> breaks a host of other sections (ipc, sockets etc.) for less than
> obvious reasons. The only source files that seem to depend on the
> __OPTIMIZE__ define are a few of the other drivers and the byteswap
> macros.
> 
> I'll investigate the gcc pages to see if there is anyway to allow
> optimisation without the out-of-order stuff that makes tracing the start
> up so hard. *sigh*

Try -O1; it's much better for debugging in general.

> I assume I can't drop the -fomit-frame-pointer for the same reason
> (inline and asm blocks assuming register assigment?).

Shouldn't matter.

> On a related note should enabling -g on the kernel CFLAGS be ok? For
> some reason vmlinux kernels compiled with -g (even after being stripped)
> seem to break the bootmem allocator on my setup. I'm trying to track
> down if this is due to some linker weirdness due to the symbol table
> being bigger than physical memory even though its not actually being
> loaded into the system.

It should be OK; it sounds like a problem with the loader you're using,
at a guess.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

      reply	other threads:[~2003-01-07 21:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-06 14:33 Why do some net drivers require __OPTIMIZE__? Alex Bennee
2003-01-06 15:04 ` Richard B. Johnson
2003-01-06 15:45   ` Robert Love
2003-01-06 15:56     ` Richard B. Johnson
2003-01-06 17:48       ` Robert Love
2003-01-06 15:36 ` Alan Cox
2003-01-07 14:33   ` Alex Bennee
2003-01-07 21:58     ` Daniel Jacobowitz [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=20030107215838.GA20046@nevyn.them.org \
    --to=dan@debian.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=alex@braddahead.com \
    --cc=linux-kernel@vger.kernel.org \
    /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