[lkml]   [2006]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/4] Compile kernel with -fwhole-program --combine
    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.


    > >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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-08-24 19:07    [W:0.024 / U:35.552 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site