Philippe Mathieu-Daudé <f4...@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.hender...@linaro.org> wrote: >>>>> >>>>> This will allow a breakpoint hack to move out of AVR's translator. >>>>> >>>>> Signed-off-by: Richard Henderson <richard.hender...@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