RE: Why enforcing sw_breakpoint_from_kind() implementation in GDBserver targets

["Maciej W. Rozycki" <macro@wdc.com>]

Hi Markus,

> > > > Note that this would only concern GDBserver, other server implementations
> > > > of the remote protocol are free to support Z0 or not.  But we could decide
> > > > that all GDBserver ports have to support it.
> > >
> > > The Intel Graphics architecture uses breakpoint bits inside instructions.  There
> > > is no single breakpoint opcode as there is INT3 on IA, for example.
> > >
> > > The breakpoint can be ignored one time, which allows stepping over
> > breakpoints
> > > without having to  remove them.  This obviously only works if the breakpoint bit
> > > in the original instruction is set and the instruction is not replaced with a fixed
> > > breakpoint pattern.
> > 
> >  Hmm, it seems to me like a use case for the breakpoint kind.
> 
> 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.

> 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.  For consistency you can do it with 
both `z0' and `Z0' packets.  If you need to encode further choices (you 
write plural "breakpoint bits"), then include them with the rest of data 
in the breakpoint kind field (i.e. either set the breakpoint bits within 
the encoding sent or concat the information required with the instruction 
data).

  Maciej