[lkml]   [2020]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: eh_frame confusion
Michael Ellerman wrote:
> "Naveen N. Rao" <> 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/ . 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:
> 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:
> 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


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

 \ /
  Last update: 2020-03-05 13:42    [W:0.117 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site