FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-06-2011, 12:25 AM
"Joshua C."
 
Default gcc-4.6.0-10.fc15.x86_64 breaks grub-0.97-71.fc15 and later

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-0.97-71.fc15.x86_64.rpm
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???
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 02:22 AM
Bruno Wolff III
 
Default gcc-4.6.0-10.fc15.x86_64 breaks grub-0.97-71.fc15 and later

On Wed, Jul 06, 2011 at 02:25:56 +0200,
"Joshua C." <joshuacov@googlemail.com> 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-0.97-71.fc15.x86_64.rpm
> 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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 05:19 AM
"Joshua C."
 
Default gcc-4.6.0-10.fc15.x86_64 breaks grub-0.97-71.fc15 and later

2011/7/6 Bruno Wolff III <bruno@wolff.to>:
> On Wed, Jul 06, 2011 at 02:25:56 +0200,
> *"Joshua C." <joshuacov@googlemail.com> 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-0.97-71.fc15.x86_64.rpm
>> 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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 07:27 AM
Jakub Jelinek
 
Default gcc-4.6.0-10.fc15.x86_64 breaks grub-0.97-71.fc15 and later

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 07:20 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org