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, address@hidden 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