Hi Andrew,
Andrew Morton writes:
> Sorry, Graham. I screwed up - got the compiler versions tangled, ended
> up compiling with 2.7.2.3. You very sneakily determine whether the
> compiler supports -ffunction-sections and if not, fall back to the old
> behaviour.
Yes; makes it backwards compatible, but harder to ensure that it's kicking in.
Mind you, since I have to use KEEP in the .lds files, which was introduced to
help with --gc-sections, I don't know if the patch will work for folks with
very old (i.e. pre --gc-sections) binutils.
...
> An added bonus from this patch is that it allows ifdefs to be removed so
> that code can be always compiled, even if it's not required. This is a
> maintenance plus, preventing trivial mistakes from propagating.
Yes, it can mean less #ifdefs all round in fact. Unfortunately my
CONFIG_MESSAGES patch adds more, and the ext2 stuff is particularly unfriendly
because it's hard to optimise away the human-readable strings passed to the
error functions.
> Interesting that 'ld --gc-sections' takes about 15x longer than normal.
I haven't delved into this, but on PowerPC it takes no longer than normal, and
links in under a second. I think what you're seeing is platform specific.
Certainly we'd need to keep the x86 folks happy though, so we'd need to sort
this out.
> I would suggest that you make '-ffunction-sections/--gc-sections' _not_
> be the default behaviour - it's a concern that you're treading rarely
> travelled code paths through the compiler and linker. Perhaps add an
> experimental CONFIG_GC_FUNCTIONS?
As Alan pointed out, this particular road would benefit heavily from being more
travelled. I imagine it's likely to become the default settings for gcc
eventually anyway. I prefer automatic configuration wherever possible.
> I'm not sure that doing:
>
> #ifdef CONFIG_MESSAGES
> ..
> #else
> #define printk(fmt, args...)
> #endif
>
> is the best approach. After all, printk() _does_ return an int,
> although you've proven that a lot of the kernel doesn't use this return
> value.
True, I haven't ever seen anyone check the result of printk, but I guess I
would be better to go:
#define printk(fmt, args...) 1 /* Non-zero is probably better */
> Perhaps:
>
> #else
> extern inline int printk(const char *s, ...)
> {
> return 0;
> }
> #endif
There's a reason I didn't do it this way: gcc-2.95.2 will still include the
format string in the .rodata section even though it optimises away the inlined
printk function. Eliminating the format strings is a significant part of the
savings in turning off CONFIG_MESSAGES, so the macro version is a bigger win.
I consider this a bug in gcc-2.95.2 which I might be able to get the gcc folks
to fix...
Regards,
Graham
-- Graham Stoney Principal Hardware/Software Engineer Canon Information Systems Research Australia Ph: +61 2 9805 2909 Fax: +61 2 9805 2929- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:10 EST