On 02/03/2020 18.32, Naveen N. Rao wrote: > Naveen N. Rao wrote: >> Michael opened a task to look into this recently and I had spent some >> time last week on this. The original commit/discussion adding >> -fno-dwarf2-cfi-asm refers to R_PPC64_REL32 relocations not being >> handled by our module loader: >> http://lkml.kernel.org/r/20090224065112.GA6690@xxxxxxxxxxxxxxxxxxxxxx >> >> However, that is now handled thanks to commit 9f751b82b491d: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f751b82b491d >> >> >> I did a test build and a simple module loaded fine, so I think >> -fno-dwarf2-cfi-asm is not required anymore, unless Michael has seen >> some breakages with it. Michael? >> >>> >>> but prior to gcc-8, .eh_frame didn't seem to get generated anyway. >>> >>> Can .eh_frame sections be discarded for modules (on ppc32 at least), or >>> is there some magic that makes them necessary when building with gcc-8? >> >> As Segher points out, it looks like we need to add >> -fno-asynchronous-unwind-tables. Most other architectures seem to use >> that too. Yes. Thanks, Segher, that explains that part. > Can you check if the below patch works? I am yet to test this in more > detail, but would be good to know the implications for ppc32. I'll see if that produces a bootable kernel, but I think I'd prefer a more piecemeal approach. One patch to add -fno-asynchronous-unwind-tables (given that other arches do it unconditionally I don't think cc-option is needed), with a commit log saying something like "no-op for gcc < 8, prevents .eh_frame sections that are discarded anyway for vmlinux and waste disk space for modules". Then another patch can get rid of -fno-dwarf2-cfi-asm if that's no longer required. Rasmus
