From: Blue Swirl <blauwirbel@gmail.com>
To: Artyom Tarasenko <atar4qemu@gmail.com>
Cc: Laurent Desnogues <laurent.desnogues@gmail.com>,
peter.maydell@linaro.org, qemu-devel <qemu-devel@nongnu.org>,
Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
Date: Wed, 27 Apr 2011 20:41:48 +0300 [thread overview]
Message-ID: <BANLkTimrdXUs8vOP+jxKL4=D4Fkj2kDptw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTikO1S4663W94k1DVjOgPLGVvQtj6A@mail.gmail.com>
On Wed, Apr 27, 2011 at 7:29 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
> On Tue, Apr 26, 2011 at 8:36 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>> On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
>>> On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>>>> On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
>>>>> On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
>>>>> <laurent.desnogues@gmail.com> wrote:
>>>>> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
>>>>> > <igor.v.kovalenko@gmail.com> wrote:
>>>>> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
>>>>> >> <laurent.desnogues@gmail.com> wrote:
>>>>> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
>>>>> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
>>>>> >>>> <igor.v.kovalenko@gmail.com> wrote:
>>>>> >>>>>>> Do you have public test case?
>>>>> >>>>>>> It is possible to code this delay slot write test but real issue may
>>>>> >>>>>>> be corruption elsewhere.
>>>>> >>>>
>>>>> >>>> The test case is trivial: it's just the two instructions, branch and wrpr.
>>>>> >>>>
>>>>> >>>>> In theory there could be multiple issues including compiler induced ones.
>>>>> >>>>> I'd prefer to see some kind of reproducible testcase.
>>>>> >>>>
>>>>> >>>> Ok, attached a 40 byte long test (the first 32 bytes are not used and
>>>>> >>>> needed only because the bios entry point is 0x20).
>>>>> >>>>
>>>>> >>>> $ git pull && make && sparc64-softmmu/qemu-system-sparc64 -bios
>>>>> >>>> test-wrpr.bin -nographic
>>>>> >>>> Already up-to-date.
>>>>> >>>> make[1]: Nothing to be done for `all'.
>>>>> >>>> /mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
>>>>> >>>> Aborted
>>>>> >>>
>>>>> >>> The problem seems to be that wrpr is using a non-local
>>>>> >>> TCG tmp (cpu_tmp0).
>>>>> >>
>>>>> >> Just tried the test case with write to %pil - seems like write itself is OK.
>>>>> >> The issue appears to be with save_state() call since adding save_state
>>>>> >> to %pil case provokes the same tcg abort.
>>>>> >
>>>>> > The problem is that cpu_tmp0, not being a local tmp, doesn't
>>>>> > need to be saved across helper calls. This results in the
>>>>> > TCG "optimizer" getting rid of it even though it's later used.
>>>>> > Look at the log and you'll see what I mean :-)
>>>>>
>>>>> I'm not very comfortable with tcg yet. Would it be possible to teach
>>>>> optimizer working with delay slots? Or do I look in the wrong place.
>>>>>
>>>>
>>>> The problem is not on the TCG side, but on the target-sparc/translate.c
>>>> side:
>>>>
>>>> | case 0x32: /* wrwim, V9 wrpr */
>>>> | {
>>>> | if (!supervisor(dc))
>>>> | goto priv_insn;
>>>> | tcg_gen_xor_tl(cpu_tmp0, cpu_src1, cpu_src2);
>>>> | #ifdef TARGET_SPARC64
>>>>
>>>> Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
>>>> saved across TCG branches.
>>>>
>>>> [...]
>>>>
>>>> | case 6: // pstate
>>>> | save_state(dc, cpu_cond);
>>>> | gen_helper_wrpstate(cpu_tmp0);
>>>> | dc->npc = DYNAMIC_PC;
>>>> | break;
>>>>
>>>> save_state() calls save_npc(), which in turns might call
>>>> gen_generic_branch():
>>>
>>> Hmm. This is not the only instruction using save_state() and cpu_tmp0.
>>> At least ldd is another example.
>>>
>>>> | static inline void gen_generic_branch(target_ulong npc1, target_ulong npc2,
>>>> | TCGv r_cond)
>>>> | {
>>>> | int l1, l2;
>>>> |
>>>> | l1 = gen_new_label();
>>>> | l2 = gen_new_label();
>>>> |
>>>> | tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
>>>> |
>>>> | tcg_gen_movi_tl(cpu_npc, npc1);
>>>> | tcg_gen_br(l2);
>>>> |
>>>> | gen_set_label(l1);
>>>> | tcg_gen_movi_tl(cpu_npc, npc2);
>>>> | gen_set_label(l2);
>>>> | }
>>>>
>>>> And here is the TCG branch, which drop the TCG temp cpu_temp0.
>>>>
>>>> The solution is either to rewrite gen_generic_branch() without TCG
>>>> branches, or to use a TCG temp local instead of a TCG temp.
>>>
>>> You mean something like
>>>
>>> case 6: // pstate
>>> {
>>> TCGv r_temp;
>>>
>>> r_temp = tcg_temp_new();
>>> tcg_gen_mov_tl(r_temp, cpu_tmp0);
>>> save_state(dc, cpu_cond);
>>> gen_helper_wrpstate(r_temp);
>>> tcg_temp_free(r_temp);
>>> dc->npc = DYNAMIC_PC;
>>> }
>>> break;
>>>
>>> ?
>>> This fails with the same error message.
>>
>> Close, but you need to use tcg_temp_local_new(). Does this work?
>>
>> diff --git a/target-sparc/translate.c b/target-sparc/translate.c
>> index 3c958b2..52fa2f1 100644
>> --- a/target-sparc/translate.c
>> +++ b/target-sparc/translate.c
>> @@ -3505,9 +3505,15 @@ static void disas_sparc_insn(DisasContext * dc)
>> tcg_gen_mov_tl(cpu_tbr, cpu_tmp0);
>> break;
>> case 6: // pstate
>> - save_state(dc, cpu_cond);
>> - gen_helper_wrpstate(cpu_tmp0);
>> - dc->npc = DYNAMIC_PC;
>> + {
>> + TCGv r_tmp = tcg_temp_local_new();
>> +
>> + tcg_gen_mov_tl(r_tmp, cpu_tmp0);
>> + save_state(dc, cpu_cond);
>> + gen_helper_wrpstate(r_tmp);
>> + tcg_temp_free_ptr(r_tmp);
>> + dc->npc = DYNAMIC_PC;
>> + }
>> break;
>> case 7: // tl
>> save_state(dc, cpu_cond);
>>
>
> Yep. This (with tcg_temp_free) passes my tests, thanks!
> A bonus question: how is immediate case handled?
>
> I don't see any explicit "if (IS_IMM)" and yet it seems to produce the
> expected results for the immediate instructions.
Immediates are handled by get_src2().
next prev parent reply other threads:[~2011-04-27 17:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-10 12:29 [Qemu-devel] tcg/tcg.c:1892: tcg fatal error Artyom Tarasenko
2011-04-10 13:24 ` Aurelien Jarno
2011-04-10 14:09 ` Artyom Tarasenko
2011-04-10 14:44 ` Blue Swirl
2011-04-10 17:48 ` Artyom Tarasenko
2011-04-10 17:57 ` Blue Swirl
2011-04-10 18:35 ` Artyom Tarasenko
2011-04-10 18:52 ` Igor Kovalenko
2011-04-10 19:37 ` Artyom Tarasenko
[not found] ` <BANLkTik2NChYi8hADjCSbjdZeyP_oo8_Qg@mail.gmail.com>
2011-04-10 20:00 ` Artyom Tarasenko
2011-04-11 3:16 ` Igor Kovalenko
2011-04-11 17:53 ` Artyom Tarasenko
2011-04-12 2:14 ` Igor Kovalenko
2011-04-21 14:57 ` Artyom Tarasenko
2011-04-21 15:44 ` Laurent Desnogues
2011-04-21 19:45 ` Igor Kovalenko
2011-04-21 22:39 ` Laurent Desnogues
2011-04-22 14:14 ` Igor Kovalenko
2011-04-25 20:29 ` Aurelien Jarno
2011-04-26 3:34 ` Igor Kovalenko
2011-04-26 16:26 ` Artyom Tarasenko
2011-04-26 18:07 ` Igor Kovalenko
2011-04-26 17:02 ` Artyom Tarasenko
2011-04-26 18:36 ` Blue Swirl
2011-04-26 19:07 ` Igor Kovalenko
2011-04-26 20:07 ` Blue Swirl
2011-04-26 21:35 ` Igor Kovalenko
2011-04-27 17:40 ` Blue Swirl
2011-04-27 16:29 ` Artyom Tarasenko
2011-04-27 17:41 ` Blue Swirl [this message]
2011-04-10 14:59 ` Peter Maydell
2011-04-10 17:31 ` Artyom Tarasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTimrdXUs8vOP+jxKL4=D4Fkj2kDptw@mail.gmail.com' \
--to=blauwirbel@gmail.com \
--cc=atar4qemu@gmail.com \
--cc=aurelien@aurel32.net \
--cc=laurent.desnogues@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).