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.
In this precise case the problem seems to be related to the following code
in tcg/i386/tcg-target.c:
| /* ??? We assume all operations have left us with register contents
| that are zero extended. So far this appears to be true. If we
| want to enforce this, we can either do an explicit zero-extension
| here, or (if GUEST_BASE == 0, or a segment register is in use)
| use the ADDR32 prefix. For now, do nothing. */
| if (GUEST_BASE && guest_base_flags) {
| seg = guest_base_flags;
| offset = 0;
| } else if (TCG_TARGET_REG_BITS == 64 && offset != GUEST_BASE) {
| tcg_out_movi(s, TCG_TYPE_I64, TCG_REG_L1, GUEST_BASE);
| tgen_arithr(s, ARITH_ADD + P_REXW, TCG_REG_L1, base);
| base = TCG_REG_L1;
| offset = 0;
| }
I guess we are still in time for 2.4 to fix this, but in case it's not
possible we can apply your patch.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
