RE: Why enforcing sw_breakpoint_from_kind() implementation in GDBserver targets

Maciej W. Rozycki
2020-06-18T11:03:57Z

Hi Markus,

> > > That's the only kind of breakpoint this architecture supports. As far as I
> > understand,
> > > the kind is per-target and used to distinguish different kinds of breakpoints
> > supported
> > > by this target.
> >
> > From your description I infer you do have different kinds of breakpoints,
> > one (or more?) for each instruction.
>
> OK, one could view it that way that we have a separate breakpoint instruction
> for each instruction/operand combination.
>
> I rather view it as a bit inside every instruction.

Sure, that's fine, especially from the hardware's point of view. However
for the purpose of the RSP abstraction I think my alternative point of
view does make sense.

> > > The points I was trying to make is that we're also using gdbarch breakpoints
> > and that
> > > in order to use z packets, we'd need insert_point() to be able to store shadow
> > copies.
> > > I have not looked into that since gdbarch breakpoints worked for me and would
> > also
> > > allow sharing the code between a native target and gdbserver.
> >
> > Why do you need to store any copy in `gdbserver'? GDB keeps a record of
> > replaced instructions, so you can use it instead. Just send the original
> > instruction as the breakpoint kind.
>
> The breakpoint kind would depend on the ISA. And we'd have a real lot of them.

Well, that's just one interpretation. The breakpoint kind is really a
generic cookie each target is free to give any interpretation to. There
is no processing of this data I know of in common GDB or `gdbserver' code.

> I don't think that we'd want to encode the original instruction in the breakpoint
> kind. That's what the shadow copy inside the breakpoint object is for.

I thought you wrote you had had to choose not to use `z0'/`Z0' packets
due to the inability to utilise the breakpoint bits this way. Maybe I got
this wrong.

Maciej