[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] SPARC tcg backend bugs (was: Proposal for deprecating unsupported host OSes & architecutures),
Peter Maydell <=