KVM-16 compiled against GCC 4

DISCUSSION David Duardo 2 participants 3 messages Mar 19, 2007 2 messages not in the archive KVM

lore

Share & tools

lore

David Duardo

author

2007-03-19 15:18 UTC #0 lore raw

There seems to be a bug in the generated file qemu/i386-softmmu/op.h when compiling kvm-16 against GCC 4.

If you apply the two GCC 4 patches to the kvm-16 source:

1) http://www.busybox.net/downloads/qemu/qemu-gcc-4-all.patch
2) http://www.kju-app.org/proj/browser/trunk/patches/qemu-0.9.0-gcc4.patch

and try to compile against GCC 4 you'll get a symbol redefinition error.

The solution is to remove all "extern char mempy;" lines in qemu/i386-softmmu/op.h

So far kvm has been running very stable with the only problem being the known reboot bug.

My question is where exactly is qemu/i386-softmmu/op.h being generated? I want to patch the problem before it gets generated.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Anthony Liguori

2007-03-19 15:32 UTC #2 lore raw

In reply to a message not in the archive

Quoted 10 lines · David Duardo

There seems to be a bug in the generated file qemu/i386-softmmu/op.h when compiling kvm-16 against GCC 4.
If you apply the two GCC 4 patches to the kvm-16 source:
1) http://www.busybox.net/downloads/qemu/qemu-gcc-4-all.patch
2) http://www.kju-app.org/proj/browser/trunk/patches/qemu-0.9.0-gcc4.patch
and try to compile against GCC 4 you'll get a symbol redefinition error.

Quoted 9 lines

The solution is to remove all "extern char mempy;" lines in qemu/i386-softmmu/op.h
So far kvm has been running very stable with the only problem being the known reboot bug.
My question is where exactly is qemu/i386-softmmu/op.h being generated? I want to patch the problem before it gets generated.

dyngen generates op.h from ops.o

One thing I was thinking about last night, was that there is really no reason why i386-softmmu/op.h cannot be put into version control.

That would eliminate the need for gcc-3 while also not sacrificing functionality. You would only need gcc-3 if you wanted to hack directly on the code translator (which is presumably few people).

Of course, this is only useful for KVM (since it can assume an i386 host) but it's less invasive than my previous approach.

Regards,

Anthony Liguori

Quoted 11 lines

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Anthony Liguori

2007-03-19 15:48 UTC #4 lore raw

In reply to a message not in the archive

Quoted 18 lines · Anthony Liguori

Quoted 17 lines · David Duardo
There seems to be a bug in the generated file qemu/i386-softmmu/op.h when compiling kvm-16 against GCC 4.
If you apply the two GCC 4 patches to the kvm-16 source:
1) http://www.busybox.net/downloads/qemu/qemu-gcc-4-all.patch
2)
http://www.kju-app.org/proj/browser/trunk/patches/qemu-0.9.0-gcc4.patch
and try to compile against GCC 4 you'll get a symbol redefinition error.
The solution is to remove all "extern char mempy;" lines in qemu/i386-softmmu/op.h
So far kvm has been running very stable with the only problem being the known reboot bug.

Quoted 8 lines

Quoted 3 lines
My question is where exactly is qemu/i386-softmmu/op.h being generated? I want to patch the problem before it gets generated.
dyngen generates op.h from ops.o
One thing I was thinking about last night, was that there is really no reason why i386-softmmu/op.h cannot be put into version control.

Scratch that. We would still need op.o.

Regards,

Anthony Liguori

Quoted 4 lines

That would eliminate the need for gcc-3 while also not sacrificing functionality. You would only need gcc-3 if you wanted to hack directly on the code translator (which is presumably few people).

Quoted 23 lines

Of course, this is only useful for KVM (since it can assume an i386 host) but it's less invasive than my previous approach.
Regards,
Anthony Liguori
Quoted 14 lines
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel