[Qemu-devel] Patch for compiling with GCC 4

[Qemu-devel] Patch for compiling with GCC 4

[Christian Roue]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

Hi all,
I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2 using
--disable-gcc-check, I found compile fails as stated in configure before i
disabled gcc check..
Error message, points to a problem of dyngen not correctly detecting
function ends on i386 when last instruction is a jump. I applied following
change and successfully compiled/run qemu i386.  This extra test check for
a relative backward jump  to function exit ret,
gcc 4 apparently generates a few of these.

My small change to cvs head is :

--- dyngen.c       2008-02-13 18:54:36.000000000 +0100
+++ dyngen.c    2008-02-13 19:10:14.000000000 +0100
@@ -1474,7 +1474,7 @@
         len = p_end - p_start;
         if (len == 0)
             error("empty code for %s", name);
-        if (p_end[-1] == 0xc3) {
+        if (p_end[-1] == 0xc3 || p_end[-2] == 0xeb) {
             len--;
         } else {
             error("ret or jmp expected at the end of %s", name);

Bye
Chris.

[-- Attachment #2: Type: text/html, Size: 1482 bytes --]

Re: [Qemu-devel] Patch for compiling with GCC 4

[Paul Brook]

On Saturday 16 February 2008, Christian Roue wrote:
> Hi all,
> I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2 using
> --disable-gcc-check, I found compile fails as stated in configure before i
> disabled gcc check..
> Error message, points to a problem of dyngen not correctly detecting
> function ends on i386 when last instruction is a jump. I applied following
> change and successfully compiled/run qemu i386.  This extra test check for
> a relative backward jump  to function exit ret,
> gcc 4 apparently generates a few of these.

You patch is wrong. The dyngen error is correct.

Paul

Re: [Qemu-devel] Patch for compiling with GCC 4

[Christian Roue]

Well, I somehow felt like it was a bit brutal and probably fixing the
symptoms which is apparently the case.
Looking more carefully, compile fails in :
sh4-linux-user for function op_cmp_str_T0_T1
gcc optimization leads to a ret followed by a last assignement with a jump back.
I guess dyngen hopes to find function epilogue as the last bytes.
It's apparently the only function where it happens.

I found that adding gcc option "-fno-tree-dominator-opts" for sh4
target avoids this (I suppose) unwanted optimization.
It may be a bit brutal again ( disabling too many optims or wrong ones).
May be the op_cmp_str_T0_T1 function can be rewritten to something
that avoids this optimization.
Am I on a better track ?

Bye
Chris.


On Feb 16, 2008 9:01 PM, Paul Brook <paul@codesourcery.com> wrote:
> On Saturday 16 February 2008, Christian Roue wrote:
> > Hi all,
> > I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2 using
> > --disable-gcc-check, I found compile fails as stated in configure before i
> > disabled gcc check..
> > Error message, points to a problem of dyngen not correctly detecting
> > function ends on i386 when last instruction is a jump. I applied following
> > change and successfully compiled/run qemu i386.  This extra test check for
> > a relative backward jump  to function exit ret,
> > gcc 4 apparently generates a few of these.
>
> You patch is wrong. The dyngen error is correct.
>
> Paul
>

Re: [Qemu-devel] Patch for compiling with GCC 4

[Alexander Graf]

On Feb 17, 2008, at 9:22 PM, Christian Roue wrote:

> Well, I somehow felt like it was a bit brutal and probably fixing the
> symptoms which is apparently the case.
> Looking more carefully, compile fails in :
> sh4-linux-user for function op_cmp_str_T0_T1
> gcc optimization leads to a ret followed by a last assignement with  
> a jump back.
> I guess dyngen hopes to find function epilogue as the last bytes.
> It's apparently the only function where it happens.
>
> I found that adding gcc option "-fno-tree-dominator-opts" for sh4
> target avoids this (I suppose) unwanted optimization.
> It may be a bit brutal again ( disabling too many optims or wrong  
> ones).
> May be the op_cmp_str_T0_T1 function can be rewritten to something
> that avoids this optimization.
> Am I on a better track ?

This looks like the right approach to the symptoms. The "real fix"  
would be to move the sh4 target to TCG, but for the meantime I believe  
this is the way to go. You can already find a lot of these  
unoptimization flags autodetected in the configure script, so I guess  
that'd be the right place for a patch.

I am not sure if anybody with commit right listens, though.

Regards,

Alex

>
>
> Bye
> Chris.
>
>
> On Feb 16, 2008 9:01 PM, Paul Brook <paul@codesourcery.com> wrote:
>> On Saturday 16 February 2008, Christian Roue wrote:
>>> Hi all,
>>> I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2  
>>> using
>>> --disable-gcc-check, I found compile fails as stated in configure  
>>> before i
>>> disabled gcc check..
>>> Error message, points to a problem of dyngen not correctly detecting
>>> function ends on i386 when last instruction is a jump. I applied  
>>> following
>>> change and successfully compiled/run qemu i386.  This extra test  
>>> check for
>>> a relative backward jump  to function exit ret,
>>> gcc 4 apparently generates a few of these.
>>
>> You patch is wrong. The dyngen error is correct.
>>
>> Paul
>>
>
>

Re: [Qemu-devel] Patch for compiling with GCC 4

[Christian Roue]

Alex,
thanks for the hint.
I'll have a look at TCG.

Bye
Chris.


On Feb 18, 2008 1:07 PM, Alexander Graf <alex@csgraf.de> wrote:
>
> On Feb 17, 2008, at 9:22 PM, Christian Roue wrote:
>
> > Well, I somehow felt like it was a bit brutal and probably fixing the
> > symptoms which is apparently the case.
> > Looking more carefully, compile fails in :
> > sh4-linux-user for function op_cmp_str_T0_T1
> > gcc optimization leads to a ret followed by a last assignement with
> > a jump back.
> > I guess dyngen hopes to find function epilogue as the last bytes.
> > It's apparently the only function where it happens.
> >
> > I found that adding gcc option "-fno-tree-dominator-opts" for sh4
> > target avoids this (I suppose) unwanted optimization.
> > It may be a bit brutal again ( disabling too many optims or wrong
> > ones).
> > May be the op_cmp_str_T0_T1 function can be rewritten to something
> > that avoids this optimization.
> > Am I on a better track ?
>
> This looks like the right approach to the symptoms. The "real fix"
> would be to move the sh4 target to TCG, but for the meantime I believe
> this is the way to go. You can already find a lot of these
> unoptimization flags autodetected in the configure script, so I guess
> that'd be the right place for a patch.
>
> I am not sure if anybody with commit right listens, though.
>
> Regards,
>
> Alex
>
>
> >
> >
> > Bye
> > Chris.
> >
> >
> > On Feb 16, 2008 9:01 PM, Paul Brook <paul@codesourcery.com> wrote:
> >> On Saturday 16 February 2008, Christian Roue wrote:
> >>> Hi all,
> >>> I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2
> >>> using
> >>> --disable-gcc-check, I found compile fails as stated in configure
> >>> before i
> >>> disabled gcc check..
> >>> Error message, points to a problem of dyngen not correctly detecting
> >>> function ends on i386 when last instruction is a jump. I applied
> >>> following
> >>> change and successfully compiled/run qemu i386.  This extra test
> >>> check for
> >>> a relative backward jump  to function exit ret,
> >>> gcc 4 apparently generates a few of these.
> >>
> >> You patch is wrong. The dyngen error is correct.
> >>
> >> Paul
> >>
> >
> >
>
>
>
>

Re: [Qemu-devel] Patch for compiling with GCC 4

[Thiemo Seufer]

Alexander Graf wrote:
>
> On Feb 17, 2008, at 9:22 PM, Christian Roue wrote:
>
>> Well, I somehow felt like it was a bit brutal and probably fixing the
>> symptoms which is apparently the case.
>> Looking more carefully, compile fails in :
>> sh4-linux-user for function op_cmp_str_T0_T1
>> gcc optimization leads to a ret followed by a last assignement with a 
>> jump back.
>> I guess dyngen hopes to find function epilogue as the last bytes.
>> It's apparently the only function where it happens.
>>
>> I found that adding gcc option "-fno-tree-dominator-opts" for sh4
>> target avoids this (I suppose) unwanted optimization.
>> It may be a bit brutal again ( disabling too many optims or wrong  
>> ones).
>> May be the op_cmp_str_T0_T1 function can be rewritten to something
>> that avoids this optimization.
>> Am I on a better track ?
>
> This looks like the right approach to the symptoms. The "real fix" would 
> be to move the sh4 target to TCG,

The migration to tcg can be done gradually, fixing the immediate problem
shouldn't get too involved.

> but for the meantime I believe this is 
> the way to go. You can already find a lot of these unoptimization flags 
> autodetected in the configure script, so I guess that'd be the right 
> place for a patch.

I added those as workarounds, they should rather go away than expand to
cover even more flags.


Thiemo

Re: [Qemu-devel] Patch for compiling with GCC 4

[Christian Roue]

Thanks Thiemo.
I'll look at TCG, some more doc reading ahead apparently.

Bye
Chris

On Feb 18, 2008 9:49 PM, Thiemo Seufer <ths@networkno.de> wrote:
> Alexander Graf wrote:
> >
> > On Feb 17, 2008, at 9:22 PM, Christian Roue wrote:
> >
> >> Well, I somehow felt like it was a bit brutal and probably fixing the
> >> symptoms which is apparently the case.
> >> Looking more carefully, compile fails in :
> >> sh4-linux-user for function op_cmp_str_T0_T1
> >> gcc optimization leads to a ret followed by a last assignement with a
> >> jump back.
> >> I guess dyngen hopes to find function epilogue as the last bytes.
> >> It's apparently the only function where it happens.
> >>
> >> I found that adding gcc option "-fno-tree-dominator-opts" for sh4
> >> target avoids this (I suppose) unwanted optimization.
> >> It may be a bit brutal again ( disabling too many optims or wrong
> >> ones).
> >> May be the op_cmp_str_T0_T1 function can be rewritten to something
> >> that avoids this optimization.
> >> Am I on a better track ?
> >
> > This looks like the right approach to the symptoms. The "real fix" would
> > be to move the sh4 target to TCG,
>
> The migration to tcg can be done gradually, fixing the immediate problem
> shouldn't get too involved.
>
> > but for the meantime I believe this is
> > the way to go. You can already find a lot of these unoptimization flags
> > autodetected in the configure script, so I guess that'd be the right
> > place for a patch.
>
> I added those as workarounds, they should rather go away than expand to
> cover even more flags.
>
>
> Thiemo
>
>
>