Modifications on gdbserver

Modifications on gdbserver

[Sérgio Durigan Júnior]

Hello guys,

I'm extending gdbserver in order to accept new types of hardware  
breakpoints/watchpoints, and trying to figure out how to do this in the best 
way.  Specifically, right now I'm implementing the support for hardware ranged 
breakpoints (one will be able to specify an address and a range, and GDB will 
stop whenever the inferior executes code within this range), and there are 
some ways to do it:

1) I could extend the remote protocol and include one more type of `Z' packet 
(`Z5', for example) which would represent this type of hardware breakpoint.

2) I could extend the existing `Z1' (hardware breakpoint) packet in order to 
include a "length" (or "range") parameter.  This will be different from the 
existing "size" parameter, because "size" is currently used the size of the 
instruction on the architecture.

What do you think?  Considering that there will be more "special" types of 
hardware breakpoints/watchpoints, probably I should choose (2) and try to 
modify the remote protocol as few as possible.  Do you agree?  Also, do you 
see other option(s) that could be better for this case?

Best regards,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil

Re: Modifications on gdbserver

[Daniel Jacobowitz]

On Tue, Sep 29, 2009 at 04:40:14PM -0300, Sérgio Durigan Júnior wrote:
> 1) I could extend the remote protocol and include one more type of `Z' packet 
> (`Z5', for example) which would represent this type of hardware breakpoint.
> 
> 2) I could extend the existing `Z1' (hardware breakpoint) packet in order to 
> include a "length" (or "range") parameter.  This will be different from the 
> existing "size" parameter, because "size" is currently used the size of the 
> instruction on the architecture.
> 
> What do you think?  Considering that there will be more "special" types of 
> hardware breakpoints/watchpoints, probably I should choose (2) and try to 
> modify the remote protocol as few as possible.  Do you agree?  Also, do you 
> see other option(s) that could be better for this case?

The vital thing to remember when modifying the remote protocol is to
be compatible.  We shouldn't send packets to existing servers that
won't understand them.  So I think (1) is better, because then we can
probe for the existance of the new packet and refuse to set
watchpoints if the target can't implement them.  If you change an
existing packet, it's impossible to guess all the ways existing
servers will parse it incorrectly :-)

New packets are a hassle to add, enable, probe, and document, but it's
mechanical and safe.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Modifications on gdbserver

[Sérgio Durigan Júnior]

Hi Daniel,

On Tuesday 29 September 2009, Daniel Jacobowitz wrote:
> On Tue, Sep 29, 2009 at 04:40:14PM -0300, Sérgio Durigan Júnior wrote:
> > 1) I could extend the remote protocol and include one more type of `Z'
> > packet (`Z5', for example) which would represent this type of hardware
> > breakpoint.
> >
> > 2) I could extend the existing `Z1' (hardware breakpoint) packet in order
> > to include a "length" (or "range") parameter.  This will be different
> > from the existing "size" parameter, because "size" is currently used the
> > size of the instruction on the architecture.
> >
> > What do you think?  Considering that there will be more "special" types
> > of hardware breakpoints/watchpoints, probably I should choose (2) and try
> > to modify the remote protocol as few as possible.  Do you agree?  Also,
> > do you see other option(s) that could be better for this case?
> 
> The vital thing to remember when modifying the remote protocol is to
> be compatible.  We shouldn't send packets to existing servers that
> won't understand them.  So I think (1) is better, because then we can
> probe for the existance of the new packet and refuse to set
> watchpoints if the target can't implement them.  If you change an
> existing packet, it's impossible to guess all the ways existing
> servers will parse it incorrectly :-)

You are right, I wasn't thinking about backwards-compatibility.  I am probably 
going to have to add some more packets to the protocol because there are other 
special types of breakpoints/watchpoints that I would like to add.  I will 
certainly ask for more opinions if I get stuck.

Thank you for answering this,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil