From: Michael Ellerman <mpe@ellerman.id.au>
To: "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"linuxppc-dev\@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: eh_frame confusion
Date: Tue, 03 Mar 2020 21:28:25 +1100 [thread overview]
Message-ID: <877e01spfa.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <1583168442.ovqnxu16tp.naveen@linux.ibm.com>
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com> 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@bombadil.infradead.org
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.
cheers
next prev parent reply other threads:[~2020-03-03 10:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-02 10:56 eh_frame confusion Rasmus Villemoes
2020-03-02 12:44 ` Segher Boessenkool
2020-03-02 17:17 ` Naveen N. Rao
2020-03-02 17:09 ` Naveen N. Rao
2020-03-02 17:32 ` Naveen N. Rao
2020-03-03 9:50 ` Rasmus Villemoes
2020-03-05 12:47 ` Naveen N. Rao
2020-03-03 10:28 ` Michael Ellerman [this message]
2020-03-05 12:41 ` Naveen N. Rao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877e01spfa.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=naveen.n.rao@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox