[Qemu-devel] X86_64 (AMD64) build segfaults

[Qemu-devel] X86_64 (AMD64) build segfaults

[developer]

when trying to compile qemu i get always a segfault. My system is uniarch x86_64, cc version 3.4.3
, did happen with 3.3 too.

tried snapshot and 0.6.1, no difference - getting only

target-i386/op.c:374: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

where to send the full bugreport to ?

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[Paul Brook]

On Thursday 21 April 2005 15:34, developer@isl-gbr.de wrote:
> when trying to compile qemu i get always a segfault. My system is uniarch
> x86_64, cc version 3.4.3 , did happen with 3.3 too.
>
> tried snapshot and 0.6.1, no difference - getting only
>
> target-i386/op.c:374: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
>
> where to send the full bugreport to ?

Whoever supplied your gcc.

Paul

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[developer]

i compiled it myself from source, using LFS. Everything else i compiled (and this is a complete fully working system now) absolutely without trouble. So the probability that the problem lies somewhere whithin qemu is very high. (It doesnt work with my old system, which is LFS too, but an older gcc and libs too, same error).

Removing the optimizations (the -O2) it does compile, but qemu segfaults when trying to start.

So what chances do i have ? Sending a report to gcc.gnu.org or what can i do to trace this bug down ? I have nearly no idea about assembly, which seems to be used in the part its segfaulting.




On Thu, 21 Apr 2005 15:42:18 +0100
Paul Brook <paul@codesourcery.com> wrote:

> On Thursday 21 April 2005 15:34, developer@isl-gbr.de wrote:
> > when trying to compile qemu i get always a segfault. My system is uniarch
> > x86_64, cc version 3.4.3 , did happen with 3.3 too.
> >
> > tried snapshot and 0.6.1, no difference - getting only
> >
> > target-i386/op.c:374: internal compiler error: Segmentation fault
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> >
> > where to send the full bugreport to ?
> 
> Whoever supplied your gcc.
> 
> Paul

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[Paul Brook]

On Thursday 21 April 2005 15:59, developer@isl-gbr.de wrote:
> i compiled it myself from source, using LFS. Everything else i compiled
> (and this is a complete fully working system now) absolutely without
> trouble. So the probability that the problem lies somewhere whithin qemu is
> very high. (It doesnt work with my old system, which is LFS too, but an
> older gcc and libs too, same error).

Anything that results in a gcc segfault/Internal Compiler Error is a gcc bug.
I say this as a gcc developer.

Paul

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[Paul Brook]

[Sorry to reply twice, meant to add this onto my last mail]

On Thursday 21 April 2005 15:59, developer@isl-gbr.de wrote:
> Removing the optimizations (the -O2) it does compile, but qemu segfaults
> when trying to start. 

This is normal. qemu is fairly fussy about what optimization options are used 
to compile op.c.

> So what chances do i have ? Sending a report to gcc.gnu.org or what can i
> do to trace this bug down ? I have nearly no idea about assembly, which
> seems to be used in the part its segfaulting.

See http://gcc.gnu.org/bugs.html

Paul

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[developer]

Filed a bugreport, and it seems the problem appeared once to another user, so i hope it can be fixed.

thanks,
Jochen

On Thu, 21 Apr 2005 16:01:52 +0100
Paul Brook <paul@codesourcery.com> wrote:

> On Thursday 21 April 2005 15:59, developer@isl-gbr.de wrote:
> > i compiled it myself from source, using LFS. Everything else i compiled
> > (and this is a complete fully working system now) absolutely without
> > trouble. So the probability that the problem lies somewhere whithin qemu is
> > very high. (It doesnt work with my old system, which is LFS too, but an
> > older gcc and libs too, same error).
> 
> Anything that results in a gcc segfault/Internal Compiler Error is a gcc bug.
> I say this as a gcc developer.
> 
> Paul

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[developer]

ok, just compiled the new gcc4, it doesnt segfault anymore, but i get the following error now:


/usr/src/emulator/qemu-snapshot-2005-04-21_23/target-i386/op.c
In file included from /usr/src/emulator/qemu-snapshot-2005-04-21_23/target-i386/op.c:22:
/usr/src/emulator/qemu-snapshot-2005-04-21_23/target-i386/exec.h: In function 'helper_fldt':
/usr/src/emulator/qemu-snapshot-2005-04-21_23/target-i386/exec.h:475: warning: cast to pointer from integer of different size
/usr/src/emulator/qemu-snapshot-2005-04-21_23/target-i386/exec.h: In function 'helper_fstt':
/usr/src/emulator/qemu-snapshot-2005-04-21_23/target-i386/exec.h:480: warning: cast to pointer from integer of different size
/usr/src/emulator/qemu-snapshot-2005-04-21_23/target-i386/op.c: In function 'op_goto_tb0':
/usr/src/emulator/qemu-snapshot-2005-04-21_23/target-i386/op.c:1277: warning: cast to pointer from integer of different size
/usr/src/emulator/qemu-snapshot-2005-04-21_23/target-i386/op.c: In function 'op_goto_tb1':
/usr/src/emulator/qemu-snapshot-2005-04-21_23/target-i386/op.c:1282: warning: cast to pointer from integer of different size
../dyngen -o op.h op.o
dyngen: ret or jmp expected at the end of op_bsfw_T0_cc
make[1]: *** [op.h] Error 1
make[1]: Leaving directory `/usr/src/emulator/qemu-snapshot-2005-04-21_23/i386-user'
make: *** [all] Error 1
root@smirftschs:/usr/src/emulator/qemu-snapshot-2005-04-21_23# 



any ideas for that ? :)

Jochen








On Thu, 21 Apr 2005 16:01:52 +0100
Paul Brook <paul@codesourcery.com> wrote:

> On Thursday 21 April 2005 15:59, developer@isl-gbr.de wrote:
> > i compiled it myself from source, using LFS. Everything else i compiled
> > (and this is a complete fully working system now) absolutely without
> > trouble. So the probability that the problem lies somewhere whithin qemu is
> > very high. (It doesnt work with my old system, which is LFS too, but an
> > older gcc and libs too, same error).
> 
> Anything that results in a gcc segfault/Internal Compiler Error is a gcc bug.
> I say this as a gcc developer.
> 
> Paul

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[Jonas Maebe]

On 22 apr 2005, at 16:50, developer@isl-gbr.de wrote:

> dyngen: ret or jmp expected at the end of op_bsfw_T0_cc
>
> any ideas for that ? :)

gcc 4.0 apparently performs some sort of optimization which is 
incompatible with qemu's object parser. Post the code of that routine 
to have people see what the problem is. To get it, do

objdump -d target-i386/op.o |less

search for op_bsfw_T0_cc and post the code of that routine.


Jonas

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[developer]

Hello Jonas, here is the output of the command you gave me for this function, does this help ?


0000000000001ab0 <op_bsfw_T0_cc>:
    1ab0:       89 d8                   mov    %ebx,%eax
    1ab2:       25 ff ff 00 00          and    $0xffff,%eax
    1ab7:       75 27                   jne    1ae0 <op_bsfw_T0_cc+0x30>
    1ab9:       eb 19                   jmp    1ad4 <op_bsfw_T0_cc+0x24>
    1abb:       31 d2                   xor    %edx,%edx
    1abd:       66                      data16
    1abe:       66                      data16
    1abf:       90                      nop
    1ac0:       d1 f8                   sar    %eax
    1ac2:       ff c2                   inc    %edx
    1ac4:       a8 01                   test   $0x1,%al
    1ac6:       74 f8                   je     1ac0 <op_bsfw_T0_cc+0x10>
    1ac8:       41 89 d4                mov    %edx,%r12d
    1acb:       c7 45 2c 01 00 00 00    movl   $0x1,0x2c(%rbp)
    1ad2:       eb 07                   jmp    1adb <op_bsfw_T0_cc+0x2b>
    1ad4:       c7 45 2c 00 00 00 00    movl   $0x0,0x2c(%rbp)
    1adb:       c3                      retq
    1adc:       66                      data16
    1add:       66                      data16
    1ade:       66                      data16
    1adf:       90                      nop
    1ae0:       31 d2                   xor    %edx,%edx
    1ae2:       a8 01                   test   $0x1,%al
    1ae4:       75 e2                   jne    1ac8 <op_bsfw_T0_cc+0x18>
    1ae6:       eb d3                   jmp    1abb <op_bsfw_T0_cc+0xb>
    1ae8:       66                      data16
    1ae9:       66                      data16
    1aea:       66                      data16
    1aeb:       90                      nop
    1aec:       66                      data16
    1aed:       66                      data16
    1aee:       66                      data16
    1aef:       90                      nop










On Fri, 22 Apr 2005 17:01:27 +0200
Jonas Maebe <jonas.maebe@elis.ugent.be> wrote:

> 
> On 22 apr 2005, at 16:50, developer@isl-gbr.de wrote:
> 
> > dyngen: ret or jmp expected at the end of op_bsfw_T0_cc
> >
> > any ideas for that ? :)
> 
> gcc 4.0 apparently performs some sort of optimization which is 
> incompatible with qemu's object parser. Post the code of that routine 
> to have people see what the problem is. To get it, do
> 
> objdump -d target-i386/op.o |less
> 
> search for op_bsfw_T0_cc and post the code of that routine.
> 
> 
> Jonas
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[Jonas Maebe]

On 22 apr 2005, at 17:41, developer@isl-gbr.de wrote:

> Hello Jonas, here is the output of the command you gave me for this 
> function, does this help ?

It helps in the sense that it confirms my suspicion, although I don't 
know why it creates such convoluted code. Maybe in order to have as 
small code as possible with at the same time as many aligned jump 
targets as possible. It's definitely not trivial to parse this, and 
even less trivial to rewrite it so it is usable for qemu's purposes (in 
this particular case, the retq could be replaced by a jmp, but you 
can't count on there being 4 padding bytes after each ret).

You (or someone else) will have to find a way to force gcc 4.0 to put 
one ret (or jump) at the very end of the code it generates. If that's 
not possible, it will be quite hard to support gcc 4.0 in qemu...


Jonas

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[developer]

I don't think it'll be possible for me to fix this, i don't have any knowledge about these functions at all...


On Fri, 22 Apr 2005 18:12:10 +0200
Jonas Maebe <jonas.maebe@elis.ugent.be> wrote:

> 
> On 22 apr 2005, at 17:41, developer@isl-gbr.de wrote:
> 
> > Hello Jonas, here is the output of the command you gave me for this 
> > function, does this help ?
> 
> It helps in the sense that it confirms my suspicion, although I don't 
> know why it creates such convoluted code. Maybe in order to have as 
> small code as possible with at the same time as many aligned jump 
> targets as possible. It's definitely not trivial to parse this, and 
> even less trivial to rewrite it so it is usable for qemu's purposes (in 
> this particular case, the retq could be replaced by a jmp, but you 
> can't count on there being 4 padding bytes after each ret).
> 
> You (or someone else) will have to find a way to force gcc 4.0 to put 
> one ret (or jump) at the very end of the code it generates. If that's 
> not possible, it will be quite hard to support gcc 4.0 in qemu...
> 
> 
> Jonas
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[Paul Brook]

On Friday 22 April 2005 17:12, Jonas Maebe wrote:
> On 22 apr 2005, at 17:41, developer@isl-gbr.de wrote:
> > Hello Jonas, here is the output of the command you gave me for this
> > function, does this help ?
>
> It helps in the sense that it confirms my suspicion, although I don't
> know why it creates such convoluted code. Maybe in order to have as
> small code as possible with at the same time as many aligned jump
> targets as possible. It's definitely not trivial to parse this, and
> even less trivial to rewrite it so it is usable for qemu's purposes (in
> this particular case, the retq could be replaced by a jmp, but you
> can't count on there being 4 padding bytes after each ret).
>
> You (or someone else) will have to find a way to force gcc 4.0 to put
> one ret (or jump) at the very end of the code it generates. If that's
> not possible, it will be quite hard to support gcc 4.0 in qemu...

It's not possible to force gcc4 to put the "ret" at the end of the code.

Paul

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[Jung-uk Kim]

> when trying to compile qemu i get always a segfault. My system is
> uniarch x86_64, cc version 3.4.3, did happen with 3.3 too.
>
> tried snapshot and 0.6.1, no difference - getting only
>
> target-i386/op.c:374: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.

https://bugzilla.redhat.com/beta/show_bug.cgi?id=138627
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17825

Fixed in GCC 4.0.0 and GCC 3.4.4-20050317.

> where to send the full bugreport to ?

There are many duplicates already.  Don't do that. ;-)

My 2 cents...

Jung-uk Kim

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[Jung-uk Kim]

> when trying to compile qemu i get always a segfault. My system is
> uniarch x86_64, cc version 3.4.3, did happen with 3.3 too.
>
> tried snapshot and 0.6.1, no difference - getting only
>
> target-i386/op.c:374: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.

https://bugzilla.redhat.com/beta/show_bug.cgi?id=138627
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17825

Fixed in GCC 4.0.0 and GCC 3.4.4-20050317.

> where to send the full bugreport to ?

There are many duplicates already.  So, don't do that. ;-)

My 2 cents...

Jung-uk Kim

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[Joshua Root]

FWIW, there are similar problems with gcc 4 on ppc. Dyngen dies on 
_op_bsfl_T0_cc, because the blr is in the middle of the function. The 
only way I've found to get around this is to put -O0 in the CFLAGS in 
Makefile.target. I tried the various -fno-align-* options to no avail.

In case anyone is curious, here is the code produced with -O2 and with -O0:

[-O2]
_op_bsfl_T0_cc:
0000252c        or.     r0,r24,r24
00002530        bne     0x2564
00002534        b       0x2558
00002538        srawi   r0,r0,1
0000253c        addi    r2,r2,0x1
00002540        andi.   r9,r0,0x1
00002544        beq     0x2538
00002548        li      r0,0x1
0000254c        or      r25,r2,r2
00002550        stw     r0,0x2c(r27)
00002554        b       0x2560
00002558        li      r0,_op_movl_A0_EAX
0000255c        stw     r0,0x2c(r27)
00002560        blr
00002564        andi.   r2,r0,0x1
00002568        beq     0x2574
0000256c        li      r2,_op_movl_A0_EAX
00002570        b       0x2548
00002574        li      r2,_op_movl_A0_EAX
00002578        b       0x2538

[-O0]
_op_bsfl_T0_cc:
00012304        stmw    r30,0xfff8(r1)
00012308        stwu    r1,0xffc0(r1)
0001230c        or      r30,r1,r1
00012310        or      r0,r24,r24
00012314        stw     r0,0x18(r30)
00012318        lwz     r0,0x18(r30)
0001231c        cmpwi   cr7,r0,_op_movl_A0_EAX
00012320        beq     cr7,0x12374
00012324        li      r0,_op_movl_A0_EAX
00012328        stw     r0,0x1c(r30)
0001232c        b       0x12348
00012330        lwz     r2,0x1c(r30)
00012334        addi    r0,r2,0x1
00012338        stw     r0,0x1c(r30)
0001233c        lwz     r0,0x18(r30)
00012340        srawi   r0,r0,1
00012344        stw     r0,0x18(r30)
00012348        lwz     r0,0x18(r30)
0001234c        xori    r0,r0,0x1
00012350        rlwinm  r0,r0,0,31,31
00012354        cmpwi   cr7,r0,_op_movl_A0_EAX
00012358        bne     cr7,0x12330
0001235c        lwz     r0,0x1c(r30)
00012360        or      r25,r0,r0
00012364        or      r2,r27,r27
00012368        li      r0,0x1
0001236c        stw     r0,0x2c(r2)
00012370        b       0x12380
00012374        or      r2,r27,r27
00012378        li      r0,_op_movl_A0_EAX
0001237c        stw     r0,0x2c(r2)
00012380        lwz     r1,_op_movl_A0_EAX(r1)
00012384        lmw     r30,0xfff8(r1)
00012388        blr

Cheers,
Josh

>On 22 apr 2005, at 17:41, developer@isl-gbr.de wrote:
>
>>Hello Jonas, here is the output of the command you gave me for this 
>>function, does this help ?
>
>It helps in the sense that it confirms my suspicion, although I 
>don't know why it creates such convoluted code. Maybe in order to 
>have as small code as possible with at the same time as many aligned 
>jump targets as possible. It's definitely not trivial to parse this, 
>and even less trivial to rewrite it so it is usable for qemu's 
>purposes (in this particular case, the retq could be replaced by a 
>jmp, but you can't count on there being 4 padding bytes after each 
>ret).
>
>You (or someone else) will have to find a way to force gcc 4.0 to 
>put one ret (or jump) at the very end of the code it generates. If 
>that's not possible, it will be quite hard to support gcc 4.0 in 
>qemu...
>
>Jonas

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[developer]

does this mean this problem is currently not fixable (and maybe "never" - in a considerable amount of time will ?)


On Fri, 22 Apr 2005 17:33:25 +0100
Paul Brook <paul@codesourcery.com> wrote:

> On Friday 22 April 2005 17:12, Jonas Maebe wrote:
> > On 22 apr 2005, at 17:41, developer@isl-gbr.de wrote:
> > > Hello Jonas, here is the output of the command you gave me for this
> > > function, does this help ?
> >
> > It helps in the sense that it confirms my suspicion, although I don't
> > know why it creates such convoluted code. Maybe in order to have as
> > small code as possible with at the same time as many aligned jump
> > targets as possible. It's definitely not trivial to parse this, and
> > even less trivial to rewrite it so it is usable for qemu's purposes (in
> > this particular case, the retq could be replaced by a jmp, but you
> > can't count on there being 4 padding bytes after each ret).
> >
> > You (or someone else) will have to find a way to force gcc 4.0 to put
> > one ret (or jump) at the very end of the code it generates. If that's
> > not possible, it will be quite hard to support gcc 4.0 in qemu...
> 
> It's not possible to force gcc4 to put the "ret" at the end of the code.
> 
> Paul
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[developer]

didnt find any searching through the buglist, dont know why, but i sent it already, sry :)
Any ideas when 3.4.4 will be released ?


On Fri, 22 Apr 2005 12:49:46 -0400
Jung-uk Kim <jkim@niksun.com> wrote:

> > when trying to compile qemu i get always a segfault. My system is
> > uniarch x86_64, cc version 3.4.3, did happen with 3.3 too.
> >
> > tried snapshot and 0.6.1, no difference - getting only
> >
> > target-i386/op.c:374: internal compiler error: Segmentation fault
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> 
> https://bugzilla.redhat.com/beta/show_bug.cgi?id=138627
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17825
> 
> Fixed in GCC 4.0.0 and GCC 3.4.4-20050317.
> 
> > where to send the full bugreport to ?
> 
> There are many duplicates already.  So, don't do that. ;-)
> 
> My 2 cents...
> 
> Jung-uk Kim
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[Paul Brook]

On Saturday 23 April 2005 10:05, developer@isl-gbr.de wrote:
> does this mean this problem is currently not fixable (and maybe "never" -
> in a considerable amount of time will ?)

Correct. It may be fixable, but there's basically zero interest in fixing it.
Qemu is pretty much the only place where this particular behaviour (a single 
ret at the end of the code) is required or even desirable. In fact the 
opposite is usually true - you want the fast path to be as short as possible 
for better cache locality.

IMHO the way forward long-term is to implement some sort of code generation in 
qemu. By this I mean incorporating some sort of compiler backend/optimizing 
assembler into qemu, not just writing op.c in assembly. Obviously this is a 
large chunk of work.

Paul

Re: [Qemu-devel] X86_64 (AMD64) build segfaults

[Jung-uk Kim]

On Saturday 23 April 2005 05:06 am, developer@isl-gbr.de wrote:
> didnt find any searching through the buglist, dont know why, but i
> sent it already, sry :) Any ideas when 3.4.4 will be released ?

FYI, it's coming sooner than I thought:

http://gcc.gnu.org/ml/gcc/2005-04/msg01693.html

Jung-uk Kim

> On Fri, 22 Apr 2005 12:49:46 -0400
>
> Jung-uk Kim <jkim@niksun.com> wrote:
> > > when trying to compile qemu i get always a segfault. My system
> > > is uniarch x86_64, cc version 3.4.3, did happen with 3.3 too.
> > >
> > > tried snapshot and 0.6.1, no difference - getting only
> > >
> > > target-i386/op.c:374: internal compiler error: Segmentation
> > > fault Please submit a full bug report,
> > > with preprocessed source if appropriate.
> >
> > https://bugzilla.redhat.com/beta/show_bug.cgi?id=138627
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17825
> >
> > Fixed in GCC 4.0.0 and GCC 3.4.4-20050317.
> >
> > > where to send the full bugreport to ?
> >
> > There are many duplicates already.  So, don't do that. ;-)
> >
> > My 2 cents...
> >
> > Jung-uk Kim

[Qemu-devel] Dynamic compiler future (was Re: X86_64 (AMD64) build segfaults)

[Antti P Miettinen]

Still going through the gmane archive - sorry for digging old stuff,
but.. :-)

Paul Brook <paul@codesourcery.com> writes:
> IMHO the way forward long-term is to implement some sort of code
> generation in qemu. By this I mean incorporating some sort of
> compiler backend/optimizing assembler into qemu, not just writing
> op.c in assembly. Obviously this is a large chunk of work.

Has LLVM been considered for this? I do not have practical experience
about LLVM but in principle the LLVM code generation library offers an
optimizing runtime compiler. In order to use LLVM the disas functions
would need to use the LLVM C++ API instead of generating the QEMU ops.
Hmm.. how about exceptions and having the memory access semantics of
the emulated system? LLVM probably is not aimed at supporting this
kind of things..

How about making GCC support runtime code generation? Some kind of
binary macros :-)

-- 
http://www.iki.fi/~ananaza/