Re: eh_frame confusion

On 02/03/2020 18.32, Naveen N. Rao wrote:

Naveen N. Rao wrote:

quoted

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@bombadil.infradead.org

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?

quoted

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