Re: breakpoint extension for remote protocol

["J.T. Conklin" <jtc@redbacknetworks.com>]

> Stu Grossman wrote:
> >  > Did you know
> >  > that some targets actually implement hardware breakpoints by poking the
> >  > registers directly?
> >
> > Yes, and this is a complete sin.

> And J.T. Conklin also wrote:
> > > Did you know that some targets actually implement hardware
> > > breakpoints by poking the registers directly?
> >
> > I saw that.  Yuck.
> >
> 
> Hmm, must be missing something. I don't see the problem.
> 
> Assuming that the existing GDB protocol was fixed so that system
> registers (such as the hardware breakpoint) could be correctly
> configured using `R' commands, I think it is a reasonable solution.
> In fact, I think, in many ways it is better than the alternative of
> trying to embed too many smarts in the on board ROM.

The reason I dislike the idea of GDB manipulating debug registers
directly has more to do with the state of GDB's internals than it
does with the concept itself.

* Although processors within a CPU family usually have the same user-
  level architecture, there are often major system-level differences
  of which GDB remains blissfully unaware.  In order to have generic
  embedded toolchains, GDB would have to have run-time configuration/
  selection of many different CPUs.  

  (IMO having "generic" embedded toolchains is essential.  It makes no
  sense to have multiple toolchains for essentially the same processor
  (ie. sparc, sparclite, sparclet, etc.) when one would do.)

* OK, I'll admit that my first statement is grossly simplified.  In
  fact, many CPU families have user-level differences which evolved
  as new versions have been designed.  For the most part, GDB is able
  to simply ignore the differences.  System-level differences can not
  be ignored so easily.  And when there might be a handful of user-
  level APIs, there may be many, many more if you consider system-
  level differences.

  Those targets that already have a "set processor" command to (re-)
  name registers (ie mips, sh) do so in what I consider a rather 
  klunky manner.  I'm not sure it would scale to all the user/system
  combinations.  The "register sets" idea I mentioned last month may
  help to address this, but more work is needed.

If these problems can be addressed, this might actually be a good and
valuable thing.  I have had occasions where direct access to MMU, etc. 
registers would have been useful in my projects.  But what I'm afraid
would happen is that we'll have proliferation of more and more GDBs
configs that should be one.

>     The cost of a replacing that GDB ROM monitor once it is in the
> field would be expensive when compared to the cost of tweeking the
> target specific GDB source code.  In addition, by having the
> intelligence in GDB (and the monitor just providing direct access to
> registers) it becomes easier to extend that target with additional
> functionality as it is added to GDB.

Although the upgrade costs are there, I think that many (most?) of the
designs that:

     1) have remote debugging enabled in the field
     2) use any of the CPUs supported by the GNU toolchain

will be 

     3) field upgradable.

I suspect any "monitor" would simply be a bootloader / flash upgrader,
while any GDB support will be in the application firmware itself.  At
least I hope so.  Regardless of whether GDB sends a insert hw break/
watch point command or manipulates some new register(s), the GDB stub
is going to have to be changed.

     --jtc