qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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