KVM-16 compiled against GCC 4

KVM-16 compiled against GCC 4

[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.

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

Re: KVM-16 compiled against GCC 4

[Anthony Liguori]

David Duardo wrote:
> 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.
>   

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

> -------------------------------------------------------------------------
> 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
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>   


-------------------------------------------------------------------------
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

Re: KVM-16 compiled against GCC 4

[Anthony Liguori]

Anthony Liguori wrote:
> David Duardo wrote:
>> 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.
>>   
>
> 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

> 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
>
>> ------------------------------------------------------------------------- 
>>
>> 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
>> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>>
>>   
>
>


-------------------------------------------------------------------------
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