[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-6.1 v6 11/17] hw/core: Introduce CPUClass.gdb_adjust_brea
From: |
Alex Bennée |
Subject: |
Re: [PATCH for-6.1 v6 11/17] hw/core: Introduce CPUClass.gdb_adjust_breakpoint |
Date: |
Wed, 21 Jul 2021 10:56:24 +0100 |
User-agent: |
mu4e 1.5.14; emacs 28.0.50 |
Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
> On 7/20/21 11:53 PM, Philippe Mathieu-Daudé wrote:
>> On 7/20/21 11:08 PM, Richard Henderson wrote:
>>> On 7/20/21 10:56 AM, Peter Maydell wrote:
>>>> On Tue, 20 Jul 2021 at 20:54, Richard Henderson
>>>> <richard.henderson@linaro.org> wrote:
>>>>>
>>>>> This will allow a breakpoint hack to move out of AVR's translator.
>>>>>
>>>>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
>>>>
<snip>
>>>> So previously for AVR we would have considered the bp at 0x100
>>>> and the one at 0x800100 as distinct (in the sense that the only way
>>>> the gdb remote protocol distinguishes breakpoints is by "what address",
>>>> and these have different addresses). After this change, they won't
>>>> be distinct, because if you set a bp at 0x100 and 0x800100 and then
>>>> try to remove the one at 0x100 we might remove the 0x800100 one,
>>>> because we're storing only the adjusted-address, not the one gdb used.
>
> Yes. Looks good.
>
>>>>
>>>> This might not matter in practice...
>>>
>>> I don't think it will matter.
>>>
>>> Currently, if it sets both 0x100 and 0x800100, then we'll record two
>>> breakpoints, and with either we'll raise EXCP_DEBUG when pc == 0x100.
>>>
>>> Afterward, we'll have two CPUBreakpoint structures that both contain
>>> 0x100, and when pc == 0x100 we'll raise EXCP_DEBUG. If gdb removes the
>>> breakpoint at 0x800100, we'll remove one of the two CPUBreakpoint. But
>>> we'll still stop at 0x100, as expected. When it removes the breakpoint
>>> at 0x100, both CPUBreakpoint structures will be gone.
>>>
>>> In principal, gdb could now add a breakpoint at 0x800100 and remove it
>>> with 0x100, where it could not before. But I don't expect that to
>>> happen. If we reported any kind of status to gdb re the breakpoint
>>> insertion or removal (e.g. bp not found), then it might matter, but we
>>> don't.
>
> IIUC QEMU model is "hardware breakpoint". I don't know how gdb deals
> if user add both soft/hard bp. Neither do I know how many soft/hard
> bp are "annouced" via gdbstub monitor to gdb (Alex?).
The gdbstub treats both the same and I don't think gdb cares about the
limit until we tell it we can't insert a breakpoint (which we won't
because breakpoints are infinite).
--
Alex Bennée
- [PATCH for-6.1 v6 07/17] accel/tcg: Use CF_NO_GOTO_{TB, PTR} in cpu_exec_step_atomic, (continued)
[PATCH for-6.1 v6 13/17] accel/tcg: Merge tb_find into its only caller, Richard Henderson, 2021/07/20
[PATCH for-6.1 v6 16/17] accel/tcg: Hoist tb_cflags to a local in translator_loop, Richard Henderson, 2021/07/20
[PATCH for-6.1 v6 17/17] accel/tcg: Record singlestep_enabled in tb->cflags, Richard Henderson, 2021/07/20
[PATCH for-6.1 v6 12/17] target/avr: Implement gdb_adjust_breakpoint, Richard Henderson, 2021/07/20