[PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4

[PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4

[Kyle McMartin]

From: Kyle McMartin <kyle@redhat.com>

On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
sections, which are, for the kernel, fairly pointless. Additionally, on
ppc64 this generates a relocation format which the kernel module loader
does not currently support (R_PPC64_REL32.)

Alexandre Oliva verifies that -fno-dwarf2-cfi-asm prevents this
.eh_frame section from being generated.

These seem to be used for unwinding, but it doesn't look like we
currently use them anywhere. (In fact, we explicitly dump them in the
x86_64 linker script.)

If these .eh_frame sections are eventually used, adding a per-arch
CONFIG_WANT_UNWIND check would be trivial.

(This was reported against Fedora, which appears to be the only distro
doing any building against gcc-4.4 at present: RH bz#486545.)

Signed-off-by: Kyle McMartin <kyle@redhat.com>
Cc: roland@redhat.com
Cc: aoliva@redhat.com

---
diff --git a/Makefile b/Makefile
index df6ce3e..d66a512 100644
--- a/Makefile
+++ b/Makefile
@@ -566,6 +566,11 @@ KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
 # disable pointer signed / unsigned warnings in gcc 4.0
 KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
 
+# gcc-4.4 defaults to generating .eh_frame sections, but we aren't
+# interested in those currently. additionally, it causes issues on some
+# architectures.
+KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
+
 # Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
 # But warn user when we do so
 warn-assign = \

Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4

[Sam Ravnborg]

On Tue, Feb 24, 2009 at 01:51:12AM -0500, Kyle McMartin wrote:
> From: Kyle McMartin <kyle@redhat.com>
> 
> On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
> sections, which are, for the kernel, fairly pointless. Additionally, on
> ppc64 this generates a relocation format which the kernel module loader
> does not currently support (R_PPC64_REL32.)
> 
> Alexandre Oliva verifies that -fno-dwarf2-cfi-asm prevents this
> .eh_frame section from being generated.
> 
> These seem to be used for unwinding, but it doesn't look like we
> currently use them anywhere. (In fact, we explicitly dump them in the
> x86_64 linker script.)

A grep for "eh_frame" shows too many hits in the kernel to convince
me this is true.


arch/m32r/kernel/vmlinux.lds.S:     from .altinstructions and .eh_frame */
arch/mn10300/kernel/vmlinux.lds.S:     from .altinstructions and .eh_frame */
arch/parisc/kernel/vmlinux.lds.S:        *  from .altinstructions and .eh_frame
arch/powerpc/kernel/vdso32/sigtramp.S:  .section .eh_frame,"a",@progbits
arch/powerpc/kernel/vdso32/vdso32.lds.S:        .eh_frame_hdr   : { *(.eh_frame_hdr) }   :text    :eh_frame_hdr
arch/powerpc/kernel/vdso32/vdso32.lds.S:        .eh_frame       : { KEEP (*(.eh_frame)) }:text
arch/powerpc/kernel/vdso32/vdso32.lds.S:        eh_frame_hdr    PT_GNU_EH_FRAME;
arch/powerpc/kernel/vdso64/sigtramp.S:  .section .eh_frame,"a",@progbits
arch/powerpc/kernel/vdso64/vdso64.lds.S:        .eh_frame_hdr   : { *(.eh_frame_hdr) }   :text    :eh_frame_hdr
arch/powerpc/kernel/vdso64/vdso64.lds.S:        .eh_frame       : { KEEP (*(.eh_frame)) }:text
arch/powerpc/kernel/vdso64/vdso64.lds.S:        eh_frame_hdr    PT_GNU_EH_FRAME;
arch/s390/kernel/vdso32/vdso32.lds.S:   .eh_frame_hdr   : { *(.eh_frame_hdr) }          :text     :eh_frame_hdr
arch/s390/kernel/vdso32/vdso32.lds.S:   .eh_frame       : { KEEP (*(.eh_frame)) }       :text
arch/s390/kernel/vdso32/vdso32.lds.S:   eh_frame_hdr    PT_GNU_EH_FRAME;
arch/s390/kernel/vdso64/vdso64.lds.S:   .eh_frame_hdr   : { *(.eh_frame_hdr) }          :text     :eh_frame_hdr
arch/s390/kernel/vdso64/vdso64.lds.S:   .eh_frame       : { KEEP (*(.eh_frame)) }       :text
arch/s390/kernel/vdso64/vdso64.lds.S:   eh_frame_hdr    PT_GNU_EH_FRAME;
arch/sh/kernel/vsyscall/vsyscall-sigreturn.S:   .section .eh_frame,"a",@progbits
arch/sh/kernel/vsyscall/vsyscall-trapa.S:        * fill out .eh_frame -- PFM. */
arch/sh/kernel/vsyscall/vsyscall-trapa.S:       .section .eh_frame,"a",@progbits
arch/sh/kernel/vsyscall/vsyscall.lds.S: .eh_frame_hdr   : { *(.eh_frame_hdr ) }         :text     :eh_frame_hdr
arch/sh/kernel/vsyscall/vsyscall.lds.S: .eh_frame       : {
arch/sh/kernel/vsyscall/vsyscall.lds.S:         KEEP (*(.eh_frame))
arch/sh/kernel/vsyscall/vsyscall.lds.S: eh_frame_hdr    PT_GNU_EH_FRAME;
arch/um/include/asm/common.lds.S:     from .altinstructions and .eh_frame */
arch/um/kernel/dyn.lds.S:  .eh_frame       : { KEEP (*(.eh_frame)) }
arch/x86/kernel/vmlinux_32.lds.S:     from .altinstructions and .eh_frame */
arch/x86/kernel/vmlinux_64.lds.S:     from .altinstructions and .eh_frame */
arch/x86/kernel/vmlinux_64.lds.S:       *(.eh_frame)
arch/x86/vdso/vdso-layout.lds.S:        .eh_frame_hdr   : { *(.eh_frame_hdr) }          :text     :eh_frame_hdr
arch/x86/vdso/vdso-layout.lds.S:        .eh_frame       : { KEEP (*(.eh_frame)) }       :text
arch/x86/vdso/vdso-layout.lds.S:        eh_frame_hdr    PT_GNU_EH_FRAME;
arch/x86/vdso/vdso32/int80.S:   .section .eh_frame,"a",@progbits
arch/x86/vdso/vdso32/int80.S:VDSO32_vsyscall_eh_frame_size = 0x40
arch/x86/vdso/vdso32/int80.S:   .space VDSO32_vsyscall_eh_frame_size-(.LENDFDEDLSI-.LSTARTFRAMEDLSI), 0
arch/x86/vdso/vdso32/sigreturn.S:       .section .eh_frame,"a",@progbits
arch/x86/vdso/vdso32/syscall.S: .section .eh_frame,"a",@progbits
arch/x86/vdso/vdso32/syscall.S:VDSO32_vsyscall_eh_frame_size = 0x40
arch/x86/vdso/vdso32/syscall.S: .space VDSO32_vsyscall_eh_frame_size-(.LENDFDE1-.LSTARTFRAME), 0
arch/x86/vdso/vdso32/sysenter.S:        .section .eh_frame,"a",@progbits
arch/x86/vdso/vdso32/sysenter.S:         * Emit a symbol with the size of this .eh_frame data,
arch/x86/vdso/vdso32/sysenter.S:VDSO32_vsyscall_eh_frame_size = (.LENDFDEDLSI-.LSTARTFRAMEDLSI)


x86 has a specific ".section .eh_frame,"a",@progbits" in vdso32/int80.S as one example.

Have you analyzed all these hits?

	Sam

Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4

[Alexandre Oliva]

On Feb 24, 2009, Sam Ravnborg <sam@ravnborg.org> wrote:

> On Tue, Feb 24, 2009 at 01:51:12AM -0500, Kyle McMartin wrote:
>> From: Kyle McMartin <kyle@redhat.com>
>> 
>> On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
>> sections, which are, for the kernel, fairly pointless. Additionally, on
>> ppc64 this generates a relocation format which the kernel module loader
>> does not currently support (R_PPC64_REL32.)
>> 
>> Alexandre Oliva verifies that -fno-dwarf2-cfi-asm prevents this
>> .eh_frame section from being generated.
>> 
>> These seem to be used for unwinding, but it doesn't look like we
>> currently use them anywhere. (In fact, we explicitly dump them in the
>> x86_64 linker script.)

> A grep for "eh_frame" shows too many hits in the kernel to convince
> me this is true.

I don't know whether .eh_frame is used for anything in the kernel.  It
doesn't matter, as far as the patch is concerned.

What the flag above does is to restore the .eh_frame behavior from GCC
4.3, in which, when compiling with -g, rather than using .cfi assembler
directives, GCC emitted .debug_frame and (when needed) .eh_frame itself.

The "when needed" is key.  The assembler doesn't know which of these to
emit, so it emits both in response to .cfi directives.  It's also
possible that the assembler selects more efficient relocations than GCC.
Regardless, it's precisely the presence of new relocations in .eh_frame
that caused the reported problem.

This flag will just restore the .eh_frame that you had with earlier
versions of GCC, so that you don't have to cope with the enlarged and
possibly modified one that the combination of new GCC and new binutils
generates when compiling with -g.  It will thus still serve whatever
purpose it did before.

I hope this helps,

-- 
Alexandre Oliva           http://www.lsd.ic.unicamp.br/~oliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4

[Kyle McMartin]

On Tue, Feb 24, 2009 at 09:40:34AM +0100, Sam Ravnborg wrote:
> x86 has a specific ".section .eh_frame,"a",@progbits" in vdso32/int80.S as one example.
> 
> Have you analyzed all these hits?
> 

These aren't effected by the patch. All the occurances of it inside the
kernel are explicitly written for the vdso/vsyscall functionality (which
needs it, since it's mapped into a userspace task, and you obviously
might be running a debugger on it.) The other hit in x86_64 is just a
discard section of the linker script.

regards, Kyle

Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4

[Roland McGrath]

The patch is right though the log entry and comment are perhaps misleading.
The effect of the patch is to restore the compiler behavior to what it was
before.  What it was before includes cases of producing .eh_frame and cases
of not producing it.  The default behavior of a gcc-4.4 that was built
against new enough binutils has diverged, so that some situations that
before produced no .eh_frame now do produce one.  -fno-dwarf2-cfi-asm
tells gcc to behave like it did before (which is also how 4.4 behaves when
built against an old enough binutils).


Thanks,
Roland

Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4

[Sam Ravnborg]

On Tue, Feb 24, 2009 at 01:51:12AM -0500, Kyle McMartin wrote:
> From: Kyle McMartin <kyle@redhat.com>
> 
> On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
> sections, which are, for the kernel, fairly pointless. Additionally, on
> ppc64 this generates a relocation format which the kernel module loader
> does not currently support (R_PPC64_REL32.)
> 
> Alexandre Oliva verifies that -fno-dwarf2-cfi-asm prevents this
> .eh_frame section from being generated.
> 
> These seem to be used for unwinding, but it doesn't look like we
> currently use them anywhere. (In fact, we explicitly dump them in the
> x86_64 linker script.)
> 
> If these .eh_frame sections are eventually used, adding a per-arch
> CONFIG_WANT_UNWIND check would be trivial.
> 
> (This was reported against Fedora, which appears to be the only distro
> doing any building against gcc-4.4 at present: RH bz#486545.)
> 
> Signed-off-by: Kyle McMartin <kyle@redhat.com>
> Cc: roland@redhat.com
> Cc: aoliva@redhat.com

Kyle - can you resend wit an updated changelog reflecting the comments
from Roland and Alexandre.

I got it wrong when reading the above - so chances are others does too.

Thanks,
	Sam

Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4

[Kyle McMartin]

On Wed, Feb 25, 2009 at 06:47:07AM +0100, Sam Ravnborg wrote:
> > On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
> > sections, which are, for the kernel, fairly pointless. Additionally, on
> > ppc64 this generates a relocation format which the kernel module loader
> > does not currently support (R_PPC64_REL32.)
> > 
> > Alexandre Oliva verifies that -fno-dwarf2-cfi-asm prevents this
> > .eh_frame section from being generated.
> > 
> > These seem to be used for unwinding, but it doesn't look like we
> > currently use them anywhere. (In fact, we explicitly dump them in the
> > x86_64 linker script.)
> > 
> > If these .eh_frame sections are eventually used, adding a per-arch
> > CONFIG_WANT_UNWIND check would be trivial.
> > 
> > (This was reported against Fedora, which appears to be the only distro
> > doing any building against gcc-4.4 at present: RH bz#486545.)
> > 
> > Signed-off-by: Kyle McMartin <kyle@redhat.com>
> > Cc: roland@redhat.com
> > Cc: aoliva@redhat.com
> 
> Kyle - can you resend wit an updated changelog reflecting the comments
> from Roland and Alexandre.
> 
> I got it wrong when reading the above - so chances are others does too.
> 

Yes, certainly. My apologies, I let my frustration leak through a little
into the changelog. :)

regards, Kyle