Re: [Lightning] About 32 and 64 bits registers

[Paulo César Pereira de Andrade]

Em 25 de agosto de 2010 19:41, Paulo César Pereira de Andrade
<address@hidden> escreveu:

  Crap, sorry, I think I figured what is wrong :-)

  It is the logic in jit_movi_l that does not sign extend the constant
0x80000001
and pushes the argument without sign extension... Cannot just alias jit_movi_i
to jit_movi_l...

> Em 25 de agosto de 2010 06:51, Paolo Bonzini <address@hidden> escreveu:
>> On 08/25/2010 11:04 AM, Paulo César Pereira de Andrade wrote:
>>>
>>> Actually you already did that:-)  It was the regressions in
>>> ld*_{c,uc,s,us,i,ui} where it would not sign extend negative values.
>>
>> Ah, I was thinking of getarg.
>
>  It may be related, but following on @subject, I started doing some
> debugging to find the reason of the first failure in args.tst. Since I
> am more of a "high level" C programmer, I do not understand very
> well some details of the x86_64 processor, so, while debugging here,
> I will try to describe the first problem, so, maybe you can see what
> is going wrong:
>
> $ gdb
> $ (gdb) r -v3 args.tst
> [...]   <- just to get printf pointer, could have it as a pending breakpoint
> $ (gdb) b printf
> [...]
> $ (gdb) r -v3 args.tst
> [...]
> Breakpoint 1, 0x00007ffff7209290 in printf () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00007ffff7209290 in printf () from /lib64/libc.so.6
> #1  0x00000000007d6232 in ?? ()
>
> scrolling a bit to show where the problem happens:
>
> [...]
> tested_usul:
>          0x7d61bc      mov    %r8,%rax
>                        4c 89 c0
>          0x7d61bf      movabs $0x7d3288,%rbx
>                        48 bb 88 32 7d 00 00 00 00 00
>          0x7d61c9      movslq (%rbx),%r10
>                        4c 63 13
>          0x7d61cc      cmp    %r10d,%eax
>                        44 39 d0
>          0x7d61cf      je     0x7d61f7 # tested_ii
>                        0f 84 22 00 00 00
>          0x7d61d5      mov    %r10,%rdx
>                        4c 89 d2
>          0x7d61d8      mov    %rax,%rsi
>                        48 89 c6
>          0x7d61db      movabs $0x7d32f4,%rax
>                        48 b8 f4 32 7d 00 00 00 00 00
>          0x7d61e5      mov    %rax,%rdi
>                        48 89 c7
>          0x7d61e8      mov    $0x0,%al
>                        b0 00
>          0x7d61ea      movabs $0x7ffff7209290,%r12
>                        49 bc 90 92 20 f7 ff 7f 00 00
>          0x7d61f4      rex.WB callq *%r12
>                        49 ff d4
> tested_ii:
>          0x7d61f7      mov    %r8,%rax
>                        4c 89 c0
>          0x7d61fa      movabs $0x7d3288,%rbx
>                        48 bb 88 32 7d 00 00 00 00 00
>          0x7d6204      movslq (%rbx),%r10
>                        4c 63 13
>          0x7d6207      cmp    %r10,%rax
>                        4c 39 d0
>          0x7d620a      je     0x7d6232 # tested_il
>                        0f 84 22 00 00 00
>          0x7d6210      mov    %r10,%rdx
>                        4c 89 d2
>          0x7d6213      mov    %rax,%rsi
>                        48 89 c6
>          0x7d6216      movabs $0x7d32f4,%rax
>                        48 b8 f4 32 7d 00 00 00 00 00
>          0x7d6220      mov    %rax,%rdi
>                        48 89 c7
>          0x7d6223      mov    $0x0,%al
>                        b0 00
>          0x7d6225      movabs $0x7ffff7209290,%r12
>                        49 bc 90 92 20 f7 ff 7f 00 00
>          0x7d622f      rex.WB callq *%r12
>                        49 ff d4
> tested_il:
>          0x7d6232      mov    %r9,%rax
> [...]
>
> The pseudo assembly (with cpp macros expanded by hand to simplify)
> of the test tool for this region is:
>
> tested_usul:
>        getarg_i        %r0 $argi
>        movi_p  %v0 glbi
>        ldr_i           %r1 %v0
>        beqr_i  tested_ii %r0 %r1
>        prepare 3
>                pusharg_i %r1
>                pusharg_i %r0
>                movi_p %r0 fmti
>                pusharg_p %r0
>        finish @printf
> tested_ii:
>        getarg_i        %r0 $argi
>        movi_p  %v0 glbi
>        ldr_i           %r1 %v0
>        beqr_l  tested_il %r0 %r1
>        prepare 3
>                pusharg_i %r1
>                pusharg_i %r0
>                movi_p %r0 fmti
>                pusharg_p %r0
>        finish @printf
> tested_il:
>
> where:
> o $argi is the result of jit_arg_i, in this case, mapping to %r8 (5th 
> argument,
>   {u,}long and pointer where passed on stack due to lack of registers)
> o glbi is a pointer to a global int32, in this case, holding the value
> 0x80000001
> o fmti in the pseudo assembly is:
> fmti:
> .c      " i: %lx %lx\n"
>
> and what it prints is:
>
>  i: 80000001 ffffffff80000001
>
>  I am trying to figure out why it appears %r1 was not sign extended the
> second time, e.g.:
>
>        movi_p  %v0 glbi
>        ldr_i           %r1 %v0
> or the assembly:
>          0x7d61fa      movabs $0x7d3288,%rbx
>                        48 bb 88 32 7d 00 00 00 00 00
>          0x7d6204      movslq (%rbx),%r10
>                        4c 63 13
>
> or maybe it was never sign extended, as the first test is bltr_i, and
> the second one is bltr_l.
>
>  In case it helps, in the fresh point of the failure:
> (gdb) info registers
> rax            0x7d3200 8204800
> rbx            0x7d328c 8204940
> rcx            0x8001   32769
> rdx            0xffffffff80000001       -2147483647
> rsi            0x80000001       2147483649
> rdi            0x7d32f4 8205044
> rbp            0x7fffffffbc90   0x7fffffffbc90
> rsp            0x7fffffffbc88   0x7fffffffbc88
> r8             0x80000001       2147483649
> r9             0x80000001       2147483649
> r10            0xffffffff80000001       -2147483647
> r11            0x246    582
> r12            0x7ffff7209290   140737339495056
> r13            0x7fffffffde80   140737488346752
> r14            0x0      0
> r15            0x0      0
> rip            0x7ffff7209290   0x7ffff7209290 <printf>
> eflags         0x207    [ CF PF IF ]
> cs             0x33     51
> ss             0x2b     43
> ds             0x0      0
> es             0x0      0
> fs             0x0      0
> gs             0x0      0
>
>  My main doubt, wasn't movslq (%rbx),%r10 supposed to sign extend %r10?
> Or could things gone bad and in the cmp %r10d,%eax it somehow zero'ed
> the top 32 bits? Asking because it was supposed to have been corrected
> for loads/stores, but keeping debugging here, and learning more of the
> x86_64 cpu...
>
>> Paolo
>
> Thanks,
> Paulo
>

Paulo