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? Sami
