Register names conflict in MIPS arch (bug)
Closed this issue · 2 comments
yasong commented
As we all know, there are some temporary registers named "t0-t9" in MIPS arch, which are the same as the names of the temporary registers in pyvex with the prefix "t". So there are some conflicting situations.
pyvex version in my environment is 9.0.6136.
.text:0043BB2C A0 8E 00 00 sb $t6, 0($a0)
.text:0043BB30 A0 8D 00 01 sb $t5, 1($a0)
.text:0043BB34 A0 8C 00 02 sb $t4, 2($a0)
.text:0043BB38 A0 8B 00 03 sb $t3, 3($a0)
.text:0043BB3C 24 84 00 04 addiu $a0, 4IRSB {
t0:Ity_I32 t1:Ity_I32 t2:Ity_I32 t3:Ity_I32 t4:Ity_I32 t5:Ity_I32 t6:Ity_I8 t7:Ity_I32 t8:Ity_I32 t9:Ity_I32 t10:Ity_I8 t11:Ity_I32 t12:Ity_I32 t13:Ity_I32 t14:Ity_I8 t15:Ity_I32 t16:Ity_I32 t17:Ity_I32 t18:Ity_I8 t19:Ity_I32 t20:Ity_I32 t21:Ity_I32 t22:Ity_I32
00 | ------ IMark(0x43bb2c, 4, 0) ------
01 | t5 = GET:I32(a0) # t5 is a temporary register in pyvex
02 | t7 = GET:I32(t6)
03 | t6 = 32to8(t7)
04 | STbe(t5) = t6
05 | PUT(pc) = 0x0043bb30
06 | ------ IMark(0x43bb30, 4, 0) ------
07 | t8 = Add32(t5,0x00000001) # t5 is a temporary register in pyvex (represents a0)
08 | t11 = GET:I32(t5) # t5 is a register in MIPS {.text:0043BB30 A0 8D 00 01 sb $t5, 1($a0)}
09 | t10 = 32to8(t11)
10 | STbe(t8) = t10
11 | PUT(pc) = 0x0043bb34
12 | ------ IMark(0x43bb34, 4, 0) ------
13 | t12 = Add32(t5,0x00000002)
14 | t15 = GET:I32(t4)
15 | t14 = 32to8(t15)
16 | STbe(t12) = t14
17 | PUT(pc) = 0x0043bb38
18 | ------ IMark(0x43bb38, 4, 0) ------
19 | t16 = Add32(t5,0x00000003)
20 | t19 = GET:I32(t3)
21 | t18 = 32to8(t19)
22 | STbe(t16) = t18
23 | ------ IMark(0x43bb3c, 4, 0) ------
24 | t20 = Add32(t5,0x00000004)
25 | PUT(a0) = t20
NEXT: PUT(pc) = 0x0043bb40; Ijk_Boring
}rhelmot commented
We've had this reported in the past and I believe the consensus is that it's not a bug. The IR is unambiguous - register names will only ever show up in the first argument GET and PUT statements, and temporaries will never show up there. Besides, showing register names is a pretty-printing feature and not part of the IR itself - the underlying representation is just a register file offset.