qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] target-arm: Clean up DISAS_UPDATE usage in A


From: Sergey Fedorov
Subject: Re: [Qemu-devel] [PATCH v2] target-arm: Clean up DISAS_UPDATE usage in AArch32 translation code
Date: Sat, 14 Nov 2015 00:13:47 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 10.11.2015 15:15, Peter Maydell wrote:
> So the way the 32-bit code works for singlestep is complicated
> because of the need to handle the conditional instructions,
> which means you get a lot more cases like "this is a conditional
> SWI" that need to be handled. A quick summary of some of the
> possible cases:
>
>  * unconditional normal instruction:
>     -- need to write the PC and condexec bits back to the CPU state
>     -- then take a singlestep insn (either the architectural one
>        or the EXCP_DEBUG one depending on which sort of step we are doing)
>  * unconditional exception-generating instruction
>     -- for architectural step of SWI/HVC/SMC we need to advance the
>        singlestep state machine so that they behave correctly
>     -- generate the relevant exception and then no point writing the
>        code to take EXCP_DEBUG &c because we won't get to it
>  * conditional instruction (including cond. branches):
>     -- earlier code has already written back the PC for the
>        "condition passed" case
>     -- write out the code which takes the singlestep exception for
>        the "condition passed" case
>     -- then do gen_set_label(dc->condlabel)
>     -- then the code to take the single step exception after
>        executing for the "condition failed" case
>
> In particular in this bit:
>         if (dc->condjmp || !dc->is_jmp) {
>             gen_set_pc_im(dc, dc->pc);
>             dc->condjmp = 0;

Hi Peter,

Thank you a lot for your explanation! It was really helpful for
understanding the code :) One thing I wasn't sure of was whether this
"dc->condjmp = 0" means that "condition failed" codepath below will also
generate an exception whereas it shouldn't?

Getting into the way the condexec bits handled I see that
gen_set_condexec() should be called before
gen_helper_check_breakpoints(), and probably also before
gen_helper_access_check_cp_reg() because these helpers can raise an
exception. I'm going to prepare patches for that soon.

Best regards,
Sergey

>         }
> the cases when we need to update the PC are
> (a) for the condition-failed codepath of a conditional insn
> (the condition-passed codepath will already have written PC)
> (b) for a non-conditional insn that hasn't already written PC
>
> The A64 equivalent is much simpler because the only cases we
> need to handle are:
>  * exception already generated (no point writing anything)
>  * jumps (PC already written, just write code to take the step exception)
>  * everything else (write PC then take step exception)




reply via email to

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