gcc-4.6.0-10.fc15.x86_64 breaks grub-0.97-71.fc15 and later

[Joshua C.]

I've been testing with grub and found an interesting problem. When I
install the package
http://kojipkgs.fedoraproject.org/packages/grub/0.97/71.fc15/x86_64/grub-...
everything is fine and grub works as it should:

[root@localhost x86_64-redhat]# grub
Probing devices to guess BIOS drives. This may take a long time.


    GNU GRUB  version 0.97-71.fc15  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]
grub> root (hd0,1)
root (hd0,1)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  26 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+26 p
(hd0,1)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
Done.
grub> quit
quit
[root@localhost x86_64-redhat]#


When I recompile the grub-rpm and reinstall it I get this:

[root@localhost x86_64-unknown]# grub



Probing devices to guess BIOS drives. This may take a long time.


    GNU GRUB  version 0.97-71.fc15  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]
grub> root (hd0,1)
root (hd0,1)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  31 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+31 p
(hd0,1)/boot/grub/stage2 /boot/grub/grub.conf"... failed

Error 6rd: Mismatched or corrupt version of stage1/stage2
grub> quit
quit
[root@localhost x86_64-unknown]#

---------------
As you can see the difference is in the following lines:
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  26 sectors are
embedded. (with the downloaded package)
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  31 sectors are
embedded. (with the recompiled package)

All newer packages result in the same error "Error 6rd: Mismatched or
corrupt version of stage1/stage2" and grub reports that 31 sectors
have been embedded.
So why does the gcc-4.6.0-10.fc15.x86_64 breaks my package???

[Bruno Wolff III]

On Wed, Jul 06, 2011 at 02:25:56 +0200,
  "Joshua C." <joshuacov(a)googlemail.com&gt; wrote:
>  I've been testing with grub and found an interesting problem.
> When I
>  install the package
>
> http://kojipkgs.fedoraproject.org/packages/grub/0.97/71.fc15/x86_64/grub-...
>  everything is fine and grub works as it should:
>  
>  When I recompile the grub-rpm and reinstall it I get this:
>  
>  Error 6rd: Mismatched or corrupt version of stage1/stage2 
 
>  All newer packages result in the same error "Error 6rd:
> Mismatched or
>  corrupt version of stage1/stage2" and grub reports that 31 sectors
>  have been embedded.
>  So why does the gcc-4.6.0-10.fc15.x86_64 breaks my package??? 
Note that this problem has been reported as bug 718722.

[Joshua C.]

2011/7/6 Bruno Wolff III <bruno(a)wolff.to&gt;:
>  On Wed, Jul 06, 2011 at 02:25:56 +0200,
>   "Joshua C." <joshuacov(a)googlemail.com&gt; wrote:
> > I've been testing with grub and found an interesting problem. When I
> > install the package
> >
> http://kojipkgs.fedoraproject.org/packages/grub/0.97/71.fc15/x86_64/grub-...
> > everything is fine and grub works as it should:
> >
> > When I recompile the grub-rpm and reinstall it I get this:
> >
> > Error 6rd: Mismatched or corrupt version of stage1/stage2
>
> > All newer packages result in the same error "Error 6rd: Mismatched or
> > corrupt version of stage1/stage2" and grub reports that 31 sectors
> > have been embedded.
> > So why does the gcc-4.6.0-10.fc15.x86_64 breaks my package???
>
>  Note that this problem has been reported as bug 718722.
>  
I think this is a separate issue from rbz#718722. My Problem is that
the current compiler produces different results than the one used to
build the packages in koji. This shouldn't be the case. I think this
is a gcc issues not a grub problem.

[Jakub Jelinek]

On Wed, Jul 06, 2011 at 07:19:10AM +0200, Joshua C. wrote:
>  >> So why does the gcc-4.6.0-10.fc15.x86_64 breaks my
> package???
>  >
>  > Note that this problem has been reported as bug 718722.
>  >
>  
>  I think this is a separate issue from rbz#718722. My Problem is that
>  the current compiler produces different results than the one used to
>  build the packages in koji. This shouldn't be the case. I think this
>  is a gcc issues not a grub problem. 
It is much more probable it is an application bug (relying on undefined
behavior etc.) than a gcc bug, though of course gcc bug can't be ruled out.

If you suspect a miscompilation, let somebody familiar with the source code
first try to see if some gcc flags make it working again (e.g. if compiling
with -O0 makes it work, or -O2 -fno-strict-aliasing, etc.).  If yes, try to do
a binary search between objects compiled with the working options and
non-working to narrow the problem to one source file.  If not, do a similar
binary search between older compiler compiled objects and new compiler
compiled objects.

Using a debugger or debugging printouts might be alternative
to the binary search to narrow the problem down, binary search is kind of
brute force.

Once you know which source file is problematic, first compile it with -W -Wall,
look at all the warnings, see if some of them might not show up problem in the
code, if not, try to narrow down the problem to a particular function (and
see if it can be reproduced even with -fno-inline, that helps to narrow it down
to a function), noinline and optimize attributes might help with that too,
then try to create a self-contained testcase calling that
function with the right arguments and abort or somehow else signal if that
function misbehaves.

	Jakub