[PATCH] Build with -fno-dwarf2-cfi-asm

[PATCH] Build with -fno-dwarf2-cfi-asm

[Colin Watson]

I'd like to commit this for 1.97; it's important for users of recent
distributions that use GCC 4.4 by default (which is the current release
series of GCC). Otherwise, the core is too big to embed when using LVM
and RAID (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/423412).
Any objections?

2009-09-03  Colin Watson  <cjwatson@ubuntu.com>

	* configure.ac: By default, GCC 4.4 generates .eh_frame sections
	containing unwind information in some cases where it previously did
	not. Use -fno-dwarf2-cfi-asm if available to restore the old
	behaviour. See http://patchwork.kernel.org/patch/8555/ for related
	discussion.

Index: configure.ac
===================================================================
--- configure.ac	(revision 2561)
+++ configure.ac	(working copy)
@@ -246,6 +246,21 @@
       TARGET_CFLAGS="$TARGET_CFLAGS -malign-jumps=1 -malign-loops=1 -malign-functions=1"
     fi
   fi
+
+  # By default, GCC 4.4 generates .eh_frame sections containing unwind
+  # information in some cases where it previously did not. GRUB doesn't need
+  # these and they just use up vital space. Restore the old compiler
+  # behaviour.
+  AC_CACHE_CHECK([whether -fno-dwarf2-cfi-asm works], [grub_cv_cc_fno_dwarf2_cfi_asm], [
+    CFLAGS="$CFLAGS -fno-dwarf2-cfi-asm"
+    AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
+		      [grub_cv_cc_fno_dwarf2_cfi_asm=yes],
+		      [grub_cv_cc_fno_dwarf2_cfi_asm=no])
+  ])
+
+  if test "x$grub_cv_cc_fno_dwarf2_cfi_asm" = xyes; then
+    TARGET_CFLAGS="$TARGET_CFLAGS -fno-dwarf2-cfi-asm"
+  fi
 fi
 
 grub_apple_target_cc

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: [PATCH] Build with -fno-dwarf2-cfi-asm

[Colin Watson]

I broke gcc < 4.4 by mistake, sorry. Updated patch follows.

With this patch and './grub-mkimage -d . -o tmp biosdisk ext2 part_msdos
raid mdraid lvm fs_uuid':

  gcc 4.3: 30370 bytes
  gcc 4.4: 30331 bytes

(Before this patch, gcc 4.4 produced an image that was 33000-some-odd
bytes.)

2009-09-03  Colin Watson  <cjwatson@ubuntu.com>

	* configure.ac: By default, GCC 4.4 generates .eh_frame sections
	containing unwind information in some cases where it previously did
	not. Use -fno-dwarf2-cfi-asm if available to restore the old
	behaviour. See http://patchwork.kernel.org/patch/8555/ for related
	discussion.

Index: configure.ac
===================================================================
--- configure.ac	(revision 2561)
+++ configure.ac	(working copy)
@@ -246,6 +246,23 @@
       TARGET_CFLAGS="$TARGET_CFLAGS -malign-jumps=1 -malign-loops=1 -malign-functions=1"
     fi
   fi
+
+  # By default, GCC 4.4 generates .eh_frame sections containing unwind
+  # information in some cases where it previously did not. GRUB doesn't need
+  # these and they just use up vital space. Restore the old compiler
+  # behaviour.
+  AC_CACHE_CHECK([whether -fno-dwarf2-cfi-asm works], [grub_cv_cc_fno_dwarf2_cfi_asm], [
+    SAVE_CFLAGS="$CFLAGS"
+    CFLAGS="$CFLAGS -fno-dwarf2-cfi-asm"
+    AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
+		      [grub_cv_cc_fno_dwarf2_cfi_asm=yes],
+		      [grub_cv_cc_fno_dwarf2_cfi_asm=no])
+    CFLAGS="$SAVE_CFLAGS"
+  ])
+
+  if test "x$grub_cv_cc_fno_dwarf2_cfi_asm" = xyes; then
+    TARGET_CFLAGS="$TARGET_CFLAGS -fno-dwarf2-cfi-asm"
+  fi
 fi
 
 grub_apple_target_cc

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: [PATCH] Build with -fno-dwarf2-cfi-asm

[Robert Millan]

On Thu, Sep 03, 2009 at 11:22:04AM +0100, Colin Watson wrote:
> I'd like to commit this for 1.97; it's important for users of recent
> distributions that use GCC 4.4 by default (which is the current release
> series of GCC). Otherwise, the core is too big to embed when using LVM
> and RAID (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/423412).
> Any objections?

Very nice that you found this.  I consider it a bug, and I agree it should
be fixed in 1.97.

But shouldn't this be handled by `strip' instead?  IIRC we already do it
this way for other unwanted sections.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] Build with -fno-dwarf2-cfi-asm

[Colin Watson]

On Thu, Sep 03, 2009 at 04:47:40PM +0200, Robert Millan wrote:
> On Thu, Sep 03, 2009 at 11:22:04AM +0100, Colin Watson wrote:
> > I'd like to commit this for 1.97; it's important for users of recent
> > distributions that use GCC 4.4 by default (which is the current release
> > series of GCC). Otherwise, the core is too big to embed when using LVM
> > and RAID (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/423412).
> > Any objections?
> 
> Very nice that you found this.  I consider it a bug, and I agree it should
> be fixed in 1.97.
> 
> But shouldn't this be handled by `strip' instead?  IIRC we already do it
> this way for other unwanted sections.

I just tried this out. It works in that the image is below 32KB again,
but it's 30424 bytes rather than the 30331 bytes produced by not
generating the unwind information in the first place.

Based on the discussion in the patchwork.kernel.org URL, I think that
GCC generates unwind information in two places in some cases; only one
of those corresponds to an ELF section. I'm not terribly familiar with
the details, though.

For the record, this is the patch I tested:

Index: genmk.rb
===================================================================
--- genmk.rb	(revision 2561)
+++ genmk.rb	(working copy)
@@ -58,7 +58,7 @@
 
 ifneq ($(TARGET_APPLE_CC),1)
 #{@name}: #{exe}
-	$(OBJCOPY) -O $(#{prefix}_FORMAT) --strip-unneeded -R .note -R .comment -R .note.gnu.build-id $< $@
+	$(OBJCOPY) -O $(#{prefix}_FORMAT) --strip-unneeded -R .note -R .comment -R .note.gnu.build-id -R .eh_frame -R .eh_frame_hdr $< $@
 else
 ifneq (#{exe},kernel.exec)
 #{@name}: #{exe} ./grub-macho2img
@@ -127,7 +127,7 @@
 	-rm -f $@
 	$(TARGET_CC) $(#{prefix}_LDFLAGS) $(TARGET_LDFLAGS) -Wl,-r,-d -o $@ #{pre_obj} #{mod_obj}
 	if test ! -z \"$(TARGET_OBJ2ELF)\"; then ./$(TARGET_OBJ2ELF) $@ || (rm -f $@; exit 1); fi
-	$(STRIP) --strip-unneeded -K grub_mod_init -K grub_mod_fini -K _grub_mod_init -K _grub_mod_fini -R .note -R .comment $@
+	$(STRIP) --strip-unneeded -K grub_mod_init -K grub_mod_fini -K _grub_mod_init -K _grub_mod_fini -R .note -R .comment -R .eh_frame -R .eh_frame_hdr $@
 else
 #{@name}: #{pre_obj} #{mod_obj} $(TARGET_OBJ2ELF)
 	-rm -f $@

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: [PATCH] Build with -fno-dwarf2-cfi-asm

[Robert Millan]

On Thu, Sep 03, 2009 at 04:27:57PM +0100, Colin Watson wrote:
> On Thu, Sep 03, 2009 at 04:47:40PM +0200, Robert Millan wrote:
> > On Thu, Sep 03, 2009 at 11:22:04AM +0100, Colin Watson wrote:
> > > I'd like to commit this for 1.97; it's important for users of recent
> > > distributions that use GCC 4.4 by default (which is the current release
> > > series of GCC). Otherwise, the core is too big to embed when using LVM
> > > and RAID (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/423412).
> > > Any objections?
> > 
> > Very nice that you found this.  I consider it a bug, and I agree it should
> > be fixed in 1.97.
> > 
> > But shouldn't this be handled by `strip' instead?  IIRC we already do it
> > this way for other unwanted sections.
> 
> I just tried this out. It works in that the image is below 32KB again,
> but it's 30424 bytes rather than the 30331 bytes produced by not
> generating the unwind information in the first place.
> 
> Based on the discussion in the patchwork.kernel.org URL, I think that
> GCC generates unwind information in two places in some cases; only one
> of those corresponds to an ELF section. I'm not terribly familiar with
> the details, though.

Ok.  Unless someone knows better, I'm fine with your previous approach.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] Build with -fno-dwarf2-cfi-asm

[Colin Watson]

On Thu, Sep 03, 2009 at 05:38:27PM +0200, Robert Millan wrote:
> Ok.  Unless someone knows better, I'm fine with your previous approach.

Committed, then; if somebody has a better idea they can always refine
from here.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

[PATCH] Build with -fno-dwarf2-cfi-asm

[Kyle McMartin]

From: Kyle McMartin <kyle@redhat.com>

With a sufficiently new compiler and binutils, code which wasn't
previously generating .eh_frame sections has begun to. Certain architectures
(powerpc, in this case) may generate unexpected relocation formats in
response to this, preventing modules from loading.

While the new relocation types should probably be handled, revert to
the previous behaviour with regards to generation of .eh_frame sections.

(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
Cc: sam@ravnborg.org
---

As near as I can tell, the only case previously was for the vdso images,
which are explicitly built with -fasynchronous-unwind-tables, and
annotated with cfi directives.

Everyone else either unwinds their stack manually, or has a custom
unwind format like parisc or ia64.

Hopefully this is a somewhat better description than the last time.

cheers, Kyle

diff --git a/Makefile b/Makefile
index a2c2efe..057230a 100644
--- a/Makefile
+++ b/Makefile
@@ -569,6 +569,9 @@ KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
 # disable invalid "can't wrap" optimzations for signed / pointers
 KBUILD_CFLAGS	+= $(call cc-option,-fwrapv)
 
+# revert to pre-gcc-4.4 behaviour of .eh_frame
+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 = \