linux-kernel - Re: [PATCH 0/4] Compile kernel with -fwhole-program --combine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Aug 2006 18:48:11 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	David Woodhouse <dwmw2@...radead.org>
cc:	linux-kernel@...r.kernel.org, linux-tiny@...enic.com,
	devel@...top.org
Subject: Re: [PATCH 0/4] Compile kernel with -fwhole-program --combine


>     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

> For those languages that do not support
>     IMA this option will be ignored, and the compiler will be invoked
>     once for each source file in that language.  If you use this
>     option in conjunction with `-save-temps', the compiler will
>     generate multiple pre-processed files (one for each source file),
>     but only one (combined) `.o' or `.s' file.

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.

>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? I do not think so, since EXPORT_SYMBOL explicitly puts something 
into __ksymtab/__kstrtab.
If visibility supports had been in GCC a long time ago, I am sure we would 
not need EXPORT_SYMBOL today, or rather, would do it by use of 
__attribute__() rather than a macro that ksymtabs it. Or am I possibly 
misunderstanding something?


Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/