On Sun, 9 Jul 2017, Masahiro Yamada wrote: > Hi. > > 2017-07-09 18:05 GMT+09:00 Ingo Molnar <mingo@xxxxxxxxxx>: > > > > * Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > > > >> FYI, easiest way to check if you forgot to KEEP a linker table is > >> to look at `readelf -S vmlinux` differences, and to see what is > >> being trimmed, look at nm differences or use --print-gc-sections > >> LD option to see what symbols you're trimming. Linker tables, > >> boot entry, and exception entry tends to require anchoring. > > > > Could you please add a debug build target to display all discarded > > symbols/sections? Something like: > > > > make lto-check > > > > ... or so? > > > > Thanks, > > > > Ingo > > > Actually, LTO activity existed some years ago > (but not pulled in). > > http://www.spinics.net/lists/linux-kbuild/msg09242.html > > > IIUC, this patch enables "dead code elimination", > (or "garbage collection"?), > but I think it is different from what is called LTO. Yes, it is different. With gc-sections the linker simply drops code sections that have no references to them. This is therefore fast and low complexity. LTO postpones the compiler's code optimization passes at the point where everything is linked together and can do things like constant propagation across multiple files, etc. LTO is therefore more efficient at removing unused code but compilation time is much longer due to the added complexity and inherent difficulty to parallelize the operation across multiple CPUS. I think we should aim for gc-sections to be used by default and have LTO as a possible option only. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
