On Tue, Jun 16, 2020 at 6:47 AM Sami Tolvanen <samitolvanen@xxxxxxxxxx> wrote: > > On Sat, May 23, 2020 at 8:13 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > > > > Hi Nicholas, > > (+CC: Sam Ravnborg) > > > > > > On Sat, May 23, 2020 at 7:06 PM Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > > > > > > Excerpts from Masahiro Yamada's message of May 23, 2020 3:44 am: > > > > + Michael, and PPC ML. > > > > > > > > They may know something about the reason of failure. > > > > > > Because the linker can't put branch stubs within object code sections, > > > so when you incrementally link them too large, the linker can't resolve > > > branches into other object files. > > > > > > Ah, you are right. > > > > So, this is a problem not only for PPC > > but also for ARM (both 32 and 64 bit), etc. > > > > ARM needs to insert a veneer to jump far. > > > > Prior to thin archive, we could not compile > > ARCH=arm allyesconfig because > > drivers/built-in.o was too large. > > > > This patch gets us back to the too large > > incremental object situation. > > > > With my quick compile-testing, > > ARCH=arm allyesconfig > > and ARCH=arm64 allyesconfig are broken. > > Thanks for looking into this! Clang doesn't appear to have this issue > with LTO because it always enables both -ffunction-sections and > -fdata-sections. I confirmed that -ffunction-sections also fixes arm64 > allyesconfig with this patch. While I'm fine with reusing vmlinux.o > only with LTO, how would you feel about enabling -ffunction-sections > in the kernel by default? I am OK if it works. Please do compile tests for some architectures. (especially, ARCH=powerpc defconfig, and ARCH=arm(64) allyesconfig) Thank you. -- Best Regards Masahiro Yamada
