On 14/07/2015 19:09, Aurelien Jarno wrote:
> On 2015-07-14 17:38, Leon Alrae wrote:
>> There seems to be an issue when trying to keep a pointer in bottom 32-bits
>> of a 64-bit floating point register. Load and store instructions accessing
>> this address for some reason use the whole 64-bit content of floating point
>> register rather than truncated 32-bit value. The following load uses
>> incorrect address which leads to a crash if upper 32 bits of $f0 isn't 0:
>>
>> 0x00400c60: mfc1 t8,$f0
>> 0x00400c64: lw t9,0(t8)
>>
>> It can be reproduced with the following linux userland program when running
>> on a MIPS32 with CP0.Status.FR=1 (by default mips32r5-generic and
>> mips32r6-generic CPUs have this bit set in linux-user).
>>
>> int main(int argc, char *argv[])
>> {
>> int tmp = 0x11111111;
>> /* Set f0 */
>> __asm__ ("mtc1 %0, $f0\n"
>> "mthc1 %1, $f0\n"
>> : : "r" (&tmp), "r" (tmp));
>> /* At this point $f0: w:76fff040 d:1111111176fff040 */
>> __asm__ ("mfc1 $t8, $f0\n"
>> "lw $t9, 0($t8)\n"); /* <--- crash! */
>> return 0;
>> }
>>
>> Running above program in normal (non-singlestep mode) leads to:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00005555559f6f37 in static_code_gen_buffer ()
>> (gdb) x/i 0x00005555559f6f37
>> => 0x5555559f6f37 <static_code_gen_buffer+78359>: mov
>> %gs:0x0(%rbp),%ebp
>> (gdb) info registers rbp
>> rbp 0x1111111176fff040 0x1111111176fff040
>>
>> The program runs fine in singlestep mode, or with disabled TCG
>> optimizations. Also, I'm not able to reproduce it in system emulation.
>
> I am able to reproduce the problem, but for me disabling the
> optimizations doesn't help. That said the problem is just another issue
> with the "let's assume the target supports move between 32 and 64 bit
> registers". At some point we should add a paragraph to tcg/README, to
> define how handle 32 vs 64 bit registers and what the TCG targets should
> expect. We had to add special code to handle that for sparc
> (trunc_shr_i32 instruction), but also code to the optimizer to remember
> about "garbage" high bits. I am not sure someone has a global view about
> how all this code interacts.
I certainly don't have a global view, so much that I didn't think at
all of the optimizer... Instead, it looks to me like a bug in the
register allocator. In particular this code in tcg_reg_alloc_mov:
if (IS_DEAD_ARG(1) && !ts->fixed_reg && !ots->fixed_reg) {
/* the mov can be suppressed */
if (ots->val_type == TEMP_VAL_REG) {
s->reg_to_temp[ots->reg] = -1;
}
ots->reg = ts->reg;
temp_dead(s, args[1]);
}
is not covering the "itype != otype" case. In addition, the
IS_DEAD_ARG(1) case can be covered above in the
if (((NEED_SYNC_ARG(0) || ots->fixed_reg) && ts->val_type != TEMP_VAL_REG)
|| ts->val_type == TEMP_VAL_MEM) {
conditional: in this case there's no need at all to go through
itype, and it's possible to load directly into ots.
Paolo
