Messages in this thread |  | | Subject | Re: [PATCH 0/4] Compile kernel with -fwhole-program --combine | | From | David Woodhouse <> | | Date | Thu, 24 Aug 2006 18:05:10 +0100 |
| |
On Thu, 2006-08-24 at 18:48 +0200, Jan Engelhardt wrote: > > If you are compiling multiple source files, this option tells the > > driver to pass all the source files to the compiler at once (for > > those languages for which the compiler can handle this). This > > will allow intermodule analysis (IMA) to be performed by the > > compiler. Currently the only language for which this is supported > > is C. If you pass source files for multiple languages to the > > driver, using this option, the driver will invoke the compiler(s) > > that support IMA once each, passing each compiler all the source > > files appropriate for it. > > Compiling files on their own (`make drivers/foo/bar.o`) seems to make > the optimization void. Sure, most people don't stop compiling in > between. Just a note
Yeah, that's largely because my support for this in the makefiles is an evil hack. I'm sure Sam can come up with something better :)
Actually I'm not entirely sure what you write is true. It'll _build_ fs/jffs2/read.o, for example, but it still won't then use it when I make the kernel -- it'll just use fs/jffs2/jffs2.o which is built from all the C files with --combine. So the optimisation isn't lost.
> There should be an option (in the kernel's makefile system) to disable > its use, just in case `gcc *.c` gobbles up a little more RAM > than is present.
Maybe, yeah. If you look in my 'hacks' patch you'll see I actually did this for drivers/net/e1000.ko because of a known compiler bug. In an ideal world it shouldn't be necessary though -- and there is always the option of just turning off CONFIG_COMBINED_COMPILE if your compiler is buggy or your system doesn't have the balls.
> >Using a combination of these two compiler options for building kernel > >code leads to some useful optimisation -- especially with modules which > >are made up of a bunch of incestuous C files, where none of the global > >symbols actually _need_ to be visible outside the directory they reside > >in. > > For modules, we have EXPORT_SYMBOL() and any other symbols that are > 'extern' but not exported are not visible to other modules.
Indeed.
> >The same benefits can be extended to the vmlinux too, although there are > >caveats with making _everything_ static. However, it's relatively simple > >to make EXPORT_SYMBOL() automatically set the 'externally_visible' > >attribute on the symbol in question, and to introduce a new '__global' > >tag which does the same for those symbols which aren't exported to > >modules but which _are_ needed as a global symbol in vmlinux. > > Does the kernel (at least for modules) really use ELF symbol visibility > (read: __attribute__((visibility(xyz))) or -fvisibility=xyz) for > lookups?
No, I think that's something entirely different. This is just about whether something is static or not.
The -fwhole-program option makes _everything_ static -- not visible outside the object file it's compiled into. For modules that's fine, since they really don't need to provide _any_ global symbols.
For stuff compiled into the kernel, however, this can be a problem, since sometimes we _need_ a symbol to actually be global, and accessible from somewhere outside the directory it's provided by.
So to overcome this, we use GCC's __attribute__((externally_visible)) which, as documented, just makes it global again -- undoing the effect of -fwhole-program just for this _one_ symbol.
For anything which is exported by EXPORT_SYMBOL or marked ASMLINKAGE, we put the externally_visible attribute on it automatically, by modifying the EXPORT_SYMBOL* and ASMLINKAGE macros to do so. That covers a large number of the symbols which actually need to be global within vmlinux. The new '__global' tag covers the rest.
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |