RE: Why enforcing sw_breakpoint_from_kind() implementation in GDBserver targets

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