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
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?
Rasmus
On Mon, Mar 02, 2020 at 11:56:05AM +0100, 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.
Since GCC 8, we enable -fasynchronous-unwind-tables by default for
PowerPC. See https://gcc.gnu.org/r259298 .
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.
It is useful for debugging. Not many people debug the kernel like this,
of course.
Segher
From: Naveen N. Rao <hidden> Date: 2020-03-02 17:09:17
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
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.
- Naveen
From: Naveen N. Rao <hidden> Date: 2020-03-02 17:17:31
Segher Boessenkool wrote:
On Mon, Mar 02, 2020 at 11:56:05AM +0100, Rasmus Villemoes wrote:
quoted
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.
Since GCC 8, we enable -fasynchronous-unwind-tables by default for
PowerPC. See https://gcc.gnu.org/r259298 .
quoted
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.
It is useful for debugging. Not many people debug the kernel like this,
of course.
I'm trying to understand if we need that. Other architectures seems to
pass -fasynchronous-unwind-tables only for the vdso, but disable it for
the kernel build. I suppose we can do the same.
If using -fno-asynchronous-unwind-tables, would crash/perf have
problems?
- Naveen
From: Naveen N. Rao <hidden> Date: 2020-03-02 17:32:53
Naveen N. Rao wrote:
Rasmus Villemoes wrote:
quoted
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
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.
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.
- Naveen
---
@@ -239,10 +239,7 @@ KBUILD_CFLAGS += $(call cc-option,-mno-vsx)KBUILD_CFLAGS+=$(callcc-option,-mno-spe)KBUILD_CFLAGS+=$(callcc-option,-mspe=no)-# FIXME: the module load should be taught about the additional relocs-# generated by this.-# revert to pre-gcc-4.4 behaviour of .eh_frame-KBUILD_CFLAGS+=$(callcc-option,-fno-dwarf2-cfi-asm)+KBUILD_CFLAGS+=$(callcc-option,-fno-asynchronous-unwind-tables)# Never use string load/store instructions as they are# often slow when they are implemented at all
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
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2020-03-03 10:28:31
"Naveen N. Rao" [off-list ref] writes:
Rasmus Villemoes wrote:
quoted
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.
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
From: Naveen N. Rao <hidden> Date: 2020-03-05 12:41:18
Michael Ellerman wrote:
"Naveen N. Rao" [off-list ref] writes:
quoted
Rasmus Villemoes wrote:
quoted
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.
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.
quoted
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
@@ -239,10 +239,7 @@ KBUILD_CFLAGS += $(call cc-option,-mno-vsx)KBUILD_CFLAGS+=$(callcc-option,-mno-spe)KBUILD_CFLAGS+=$(callcc-option,-mspe=no)-# FIXME: the module load should be taught about the additional relocs-# generated by this.-# revert to pre-gcc-4.4 behaviour of .eh_frame-KBUILD_CFLAGS+=$(callcc-option,-fno-dwarf2-cfi-asm)+KBUILD_CFLAGS+=$(callcc-option,-fno-asynchronous-unwind-tables)
In terms of the CFI information, the primary difference I see with
-fno-dwarf2-cfi-asm is that when dumping the debug frames, CIE indicates
version 3, while otherwise (i.e., without -fno-dwarf2-cfi-asm and
with/without -fasynchronous-unwind-tables), it is version 1, regardless
of -gdwarf-2/-gdwarf-4. There are few more minor changes, but none of
these looked significant to me.
quoted hunk
# Never use string load/store instructions as they are
# often slow when they are implemented at all