Re: eh_frame confusion

[Naveen N. Rao]

Michael Ellerman wrote:
> "Naveen N. Rao" <naveen.n.rao@xxxxxxxxxxxxx> writes:
> > Rasmus Villemoes wrote:
> > > I'm building a ppc32 kernel, and noticed that after upgrading from gcc-7
> > > to gcc-8 all object files now end up having .eh_frame section. For
> > > vmlinux, that's not a problem, because they all get discarded in
> > > arch/powerpc/kernel/vmlinux.lds.S . However, they stick around in
> > > modules, which doesn't seem to be useful - given that everything worked
> > > just fine with gcc-7, and I don't see anything in the module loader that
> > > handles .eh_frame.
> > >
> > > The reason I care is that my target has a rather tight rootfs budget,
> > > and the .eh_frame section seem to occupy 10-30% of the file size
> > > (obviously very depending on the particular module).
> > >
> > > Comparing the .foo.o.cmd files, I don't see change in options that might
> > > explain this (there's a bunch of new -Wno-*, and the -mspe=no spelling
> > > is apparently no longer supported in gcc-8). Both before and after, there's
> > >
> > > -fno-dwarf2-cfi-asm
> > >
> > > about which gcc's documentation says
> > >
> > > '-fno-dwarf2-cfi-asm'
> > >      Emit DWARF unwind info as compiler generated '.eh_frame' section
> > >      instead of using GAS '.cfi_*' directives.
> > >
> > > Looking into where that comes from got me even more confused, because
> > > both arm and unicore32 say
> > >
> > > # Never generate .eh_frame
> > > KBUILD_CFLAGS           += $(call cc-option,-fno-dwarf2-cfi-asm)
> > >
> > > while the ppc32 case at hand says
> > >
> > > # FIXME: the module load should be taught about the additional relocs
> > > # generated by this.
> > > # revert to pre-gcc-4.4 behaviour of .eh_frame
> >
> > 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
>
> I opened that issue purely based on noticing the wart in the Makefile,
> not because I'd actually tested it.
>
> > However, that is now handled thanks to commit 9f751b82b491d:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f751b82b491d
>
> Haha, written by me, what an idiot.
>
> So the Makefile hack can presumably be dropped, because the module
> loader can handle the relocations.
>
> And then maybe we also want to turn off the unwind tables, but that
> would be a separate patch.
>
> > 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?
>
> No, as I said above it was just reading the Makefile.

Ok, thanks for clarifying. To test, I did 'allmodconfig' builds across 
three environments:
- gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008 -- ppc64le
- gcc (SUSE Linux) 7.5.0 -- ppc64le
- gcc (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6) -- ppc64 (BE)

Then, used the below command to list all relocations in the modules:
$ find . -name '*.ko' | xargs -n 1 readelf -Wr  | grep -v "Relocation " | grep -v "Offset " | cut -d' ' -f4 | sort | uniq

R_PPC64_ADDR32
R_PPC64_ADDR64
R_PPC64_ENTRY
R_PPC64_REL24
R_PPC64_REL32
R_PPC64_REL64
R_PPC64_TOC
R_PPC64_TOC16_HA
R_PPC64_TOC16_LO
R_PPC64_TOC16_LO_DS

All three environments show up similar set of relocations, all of which 
we handle in the module loader today.

If Rasmus/Christophe can confirm that this is true for ppc32 as well, 
then we should be fine.

- Naveen