This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: breakpoint extension for remote protocol

Stu Grossman wrote:

> Andrew Cagney writes:
>  > 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.

Compare the following (apologies up front for the lame ASCII diagrams):

    GDB cli
    high level breakpoint code
    tdep (architecture code)
    remote.c
        |
   PROTOCOL
        |
    low level break-point code
    raw GDB target

vs

    GDB cli
    high level breakpoint code
    tdep (architecture code)
    low level breakpoint code (uses remote.c)
        |
    PROTOCOL
        |
    raw GDB target

That is, the code that controls the  h/w breakpoint mechanism can either be
implemented in the local GDB or in the remote target.

I would have thought that both alternatives were valid and, if anything, GDB
(being the best debugger in the world :-) should be able to accommodate both
styles.

Remote h/w breakpoints:

    This, I think is especially useful when the remote target has significant
intelligence, almost infinite resources and an ease of update.
    Examples could be GDB talking remotely to a simulator or a gdbserver process
on a remote machine.

Local h/w breakpoints:

    This, I think is better when the remote hardware is small , lame and embedded.

    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.

    enjoy,

        Andrew