qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] SPARC tcg backend bugs (was: Proposal for deprecating unsup


From: Peter Maydell
Subject: [Qemu-devel] SPARC tcg backend bugs (was: Proposal for deprecating unsupported host OSes & architecutures)
Date: Mon, 27 Mar 2017 14:13:38 +0100

On 24 March 2017 at 17:24, Peter Maydell <address@hidden> wrote:
> So far I have found that we seem to be mishandling 32-bit guest
> load/stores, which I tentatively suggest
>
> diff --git a/tcg/sparc/tcg-target.inc.c b/tcg/sparc/tcg-target.inc.c
> index d1f4c0dead..c72b57dc58 100644
> --- a/tcg/sparc/tcg-target.inc.c
> +++ b/tcg/sparc/tcg-target.inc.c
> @@ -1119,7 +1119,7 @@ static void tcg_out_qemu_ld(TCGContext *s,
> TCGReg data, TCGReg addr,
>          /* Skip the high-part; we'll perform the extract in the trampoline.  
> */
>          param++;
>      }
> -    tcg_out_mov(s, TCG_TYPE_REG, param++, addr);
> +    tcg_out_mov(s, TCG_TYPE_REG, param++, addrz);
>
>      /* We use the helpers to extend SB and SW data, leaving the case
>         of SL needing explicit extending below.  */
> @@ -1199,7 +1199,7 @@ static void tcg_out_qemu_st(TCGContext *s,
> TCGReg data, TCGReg addr,
>          /* Skip the high-part; we'll perform the extract in the trampoline.  
> */
>          param++;
>      }
> -    tcg_out_mov(s, TCG_TYPE_REG, param++, addr);
> +    tcg_out_mov(s, TCG_TYPE_REG, param++, addrz);
>      if (!SPARC64 && (memop & MO_SIZE) == MO_64) {
>          /* Skip the high-part; we'll perform the extract in the trampoline.  
> */
>          param++;
>
> (otherwise we pass a high-bits-set value to the slowpath functions,
> which happens to work if QEMU was built with debug enabled but not
> if it doesn't.)
>
> That then at least makes i386 and x86_64 guests behave the same,
> ie they don't work. I haven't figured out what's going wrong there yet.

I've tracked this down to a similar problem: our implementation
of byte and halfword stores doesn't correctly zero/sign extend
the data value before passing it to the C helper function, which
means that if QEMU was compiled with optimization enabled we can
end up writing incorrect values to memory. Not sure what the
best fix is, though -- I guess some sign/zero extend code in
the store trampolines, but what's the best sparc code sequence
for doing 8/16 bit extension?

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]