[Top][All Lists]

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

Re: [PATCH v3 10/13] target/riscv: Reduce riscv_tr_breakpoint_check pc a

From: Richard Henderson
Subject: Re: [PATCH v3 10/13] target/riscv: Reduce riscv_tr_breakpoint_check pc advance to 2
Date: Sun, 18 Jul 2021 08:50:40 -1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 7/18/21 8:16 AM, Peter Maydell wrote:
On Sun, 18 Jul 2021 at 19:02, Richard Henderson
<richard.henderson@linaro.org> wrote:

On 7/17/21 1:35 PM, Peter Maydell wrote:
(What goes wrong if we just say "always use a TB size of 1 regardless
of target arch" rather than having the arch return the worst case
minimum insn length?)

Hmm, possibly nothing.  Perhaps I should try that and see what happens...

Some of the comments in these patches suggest it might trigger
the warning in the disassembler about length mismatches; possibly
also you might get duff (truncated) disassembly output? I suspect
that's probably the extent of the problem.

We should be able to work around this by looking at tb->icount.

After patch 13, when breakpoints are always at the beginning of the TB, we'll always have tb->icount == 0.

Thinking about this further, with the breakpoint at the head of the TB, there's really no point in emitting code for breakpoints at all. Once we've recognized that there is a breakpoint at the current PC, we should just raise the exception.

IIRC only i386 and arm have arch-specific conditional breakpoints. And, given that all cpu state is in sync when looking for bp's, we could probably make do with a callback instead of any code generation.

Let me see what I can do...


reply via email to

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