Hi,
I've been doing a bring up on an embedded kernel and to prevent gdb
making me go google eyed I notched the optimization level down to -O0
for the time being. This broke the natsemi network driver and I noticed
this stanza appears in a few places:
#if !defined(__OPTIMIZE__)
#warning You must compile this file with the correct options!
#warning See the last lines of the source file.
#error You must compile this driver with "-O".
#endif
Despite the comments I couldn't see an explanation at the bottom of the
source file and a quick google showed a few patches where this was
removed but no explanation.
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.
--
Alex Bennee
Senior Hacker, Braddahead Ltd
The above is probably my personal opinion and may not be that of my
employer
> 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.
On 6 Jan 2003, Alex Bennee wrote:
> Hi,
>
> I've been doing a bring up on an embedded kernel and to prevent gdb
> making me go google eyed I notched the optimization level down to -O0
> for the time being. This broke the natsemi network driver and I noticed
> this stanza appears in a few places:
>
> #if !defined(__OPTIMIZE__)
> #warning You must compile this file with the correct options!
> #warning See the last lines of the source file.
> #error You must compile this driver with "-O".
> #endif
>
> Despite the comments I couldn't see an explanation at the bottom of the
> source file and a quick google showed a few patches where this was
> removed but no explanation.
>
> 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.
>
> --
> Alex Bennee
> Senior Hacker, Braddahead Ltd
> The above is probably my personal opinion and may not be that of my
> employer
You need to optimize in order enable inline code generation. It is
essential to use in-line code in many places because, if the compiler
actually calls these functions they would have to be protected
from reentry.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Mon, 2003-01-06 at 10:04, Richard B. Johnson wrote:
> You need to optimize in order enable inline code generation. It is
> essential to use in-line code in many places because, if the compiler
> actually calls these functions they would have to be protected
> from reentry.
I do not think this is correct.
Concurrency concerns would not change wrt calling the function vs.
inlining it.
More likely some code, i.e. asm, just assumes inlining is taking place.
Robert Love
On 6 Jan 2003, Robert Love wrote:
> On Mon, 2003-01-06 at 10:04, Richard B. Johnson wrote:
>
> > You need to optimize in order enable inline code generation. It is
> > essential to use in-line code in many places because, if the compiler
> > actually calls these functions they would have to be protected
> > from reentry.
>
> I do not think this is correct.
>
> Concurrency concerns would not change wrt calling the function vs.
> inlining it.
>
> More likely some code, i.e. asm, just assumes inlining is taking place.
>
> Robert Love
>
When you call a function, that function gets a copy of the parameters
passed to it. In-line code accesses those parameters directly. That's
why the spin-lock code, for instance, won't work (with the current macros)
unless they are in-lined.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Mon, 2003-01-06 at 10:56, Richard B. Johnson wrote:
> When you call a function, that function gets a copy of the
> parameters passed to it. In-line code accesses those parameters
> directly. That's why the spin-lock code, for instance, won't work
> (with the current macros) unless they are in-lined.
Huh?
void dog(int i)
{
i++;
}
main()
{
int x = 1;
dog(x);
}
Are you saying x will be 2 after the call? _Wrong_
Macros, yes. Inlines, no.
Inline functions have the same behavior as callable functions, with a
few exceptions (they do not act as compiler barriers, for one).
The spin lock C functions will work fine if they are not inlined, as far
as I can tell. If not, it is just because the inline assembly assumes
they are inline (i.e. what certain registers contain, etc.).
The macros, of course, will need trivial adjustments to use pointers
instead of copies, etc.
Again, the only reason inline vs. not will break anything, as far as I
can tell, is because inline asm assumes a function is inlined.
Robert Love
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*
I assume I can't drop the -fomit-frame-pointer for the same reason
(inline and asm blocks assuming register assigment?).
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.
--
Alex Bennee
Senior Hacker, Braddahead Ltd
The above is probably my personal opinion and may not be that of my
employer
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