| Message ID | 20090224065112.GA6690@bombadil.infradead.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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
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,
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
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
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
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
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 = \