Re: [Lightning] About 32 and 64 bits registers

[Paulo César Pereira de Andrade]

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