Re: breakpoint extension for remote protocol

Re: breakpoint extension for remote protocol

[Andrew Cagney]

"J.T. Conklin" wrote:

>   (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.)

Agreed.

I think that the difficulties encountered when trying to support cpu variants
within a single GDB are more of a reflection on the GDB architecture then a
problem with the idea of having the debug smarts on the host (rather than the
target).

As Stan noted:

> Those who study recent snapshots will notice that we are doing some
> internal cleanup that will make it easier to support CPU variants
> without kludging.
>

    enjoy,

        Andrew

Re: breakpoint extension for remote protocol

[Andrew Cagney]

"J.T. Conklin" wrote:

> Here is the protocol elements that I'm currently working with:
>
>     Insert Breakpoint:     B<type>,<address>[,<length>]
>     returns:               ??   - A cookie representing the breakpoint
>                            EX   - breakpoint type not supported
>                                 - no breakpoint contexts available
>                                 - invalid/unsupported address
>                                 - invalid/unsupported length

FYI, there is already a semi-official use of `B' as a generic remote
breakpoint operation.  The syntax is:

    B<address>,S    Set a breakpoint
    B<address>,C    Clear a breakpoint

When using this, GDB assumes the target can handle all breakpoints.

With regard to the general question of extending the remote-gdb protocol
so that it supports a generic hardware breakpoint mechanism.  I agree it
is needed.  It is a missing part of the overall toolkit.  Did you know
that some targets actually implement hardware breakpoints by poking the
registers directly?

    enjoy,
        Andrew

Re: breakpoint extension for remote protocol

[Stu Grossman]

Andrew Cagney writes:
 > "J.T. Conklin" wrote:
 > 
 > > Here is the protocol elements that I'm currently working with:
 > >
 > >     Insert Breakpoint:     B<type>,<address>[,<length>]
 > >     returns:               ??   - A cookie representing the breakpoint
 > >                            EX   - breakpoint type not supported
 > >                                 - no breakpoint contexts available
 > >                                 - invalid/unsupported address
 > >                                 - invalid/unsupported length
 > 
 > FYI, there is already a semi-official use of `B' as a generic remote
 > breakpoint operation.  The syntax is:
 > 
 >     B<address>,S    Set a breakpoint
 >     B<address>,C    Clear a breakpoint

Where is this used?  I see no evidence of this in devo's remote.c.  Is it
hiding out on a branch somewhere?  FYI, the syntax is bogus.  It should use B
and b like the rest of the commands.  Also, the protocol should support the
ability to set a breakpoint or watchpoint on a range of addresses.  The command
format used by JT was developed by me many years ago, and should have been used
instead of this `semi-official' method which was apparantly done without
consultation of someone who understands how to develop this protocol.

 > With regard to the general question of extending the remote-gdb protocol
 > so that it supports a generic hardware breakpoint mechanism.  I agree it
 > is needed.  It is a missing part of the overall toolkit.

I have discussed this with GDB folk in the past.  If you want to hear what
needs to be done, ping me.

 > Did you know
 > that some targets actually implement hardware breakpoints by poking the
 > registers directly?

Yes, and this is a complete sin.

			Stu

Re: breakpoint extension for remote protocol

[J.T. Conklin]

> > FYI, there is already a semi-official use of `B' as a generic remote
> > breakpoint operation.  The syntax is:
> > 
> >     B<address>,S    Set a breakpoint
> >     B<address>,C    Clear a breakpoint
> 
> Where is this used?  I see no evidence of this in devo's remote.c.
> Is it hiding out on a branch somewhere?  FYI, the syntax is bogus.
> It should use B and b like the rest of the commands.  

Although I noticed the parallelism of the existing commands g/G, m/M,
and I recently proposed p to compliment P; I used B/D instead of b/B
because inserting and removing breakpoints don't have quite the same
type of symmetry as reading and writing memory or registers.  A read
command doesn't change the state of the target, while removing a
breakpoint certainly does.

One issue with 'b' is that it's used in the sparc* stubs to set the
baud rate of the connection.  That code has been #ifdef'd out with 
the comment "Disabled until we can unscrew this properly", so we may
be able to simply junk that.

Nevertheless if it is thought that b/B should be used, I'll make that
change.  I could roll out breakpoint support within RedBack tomorrow,
but that would be less than optimal if I had to deal with supporting
multiple versions of GDB for different releases of our software.  It's
in my interest to get the protocol extensions nailed down and agreed
upon before I deploy it (and get it contributed).

> > With regard to the general question of extending the remote-gdb protocol
> > so that it supports a generic hardware breakpoint mechanism.  I agree it
> > is needed.  It is a missing part of the overall toolkit.
> 
> I have discussed this with GDB folk in the past.  If you want to hear what
> needs to be done, ping me.

Stu, I think I implemented your design faithfully.  However, it was from 
memory of a two year old conversation.  If I've left something out, please
let me know.

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

A related sin which needs to be addressed is that there can be only
one set of hardware watchpoint and breakpoint functions (ie. they're
not in the target vector).  Now that the remote protocol can support
hardware break/watchpoints, we'll need to fix that.

	 --jtc

Re: breakpoint extension for remote protocol

[J.T. Conklin]

> Although I noticed the parallelism of the existing commands g/G, m/M,
> and I recently proposed p to compliment P; I used B/D instead of b/B
> because inserting and removing breakpoints don't have quite the same
> type of symmetry as reading and writing memory or registers.  A read
> command doesn't change the state of the target, while removing a
> breakpoint certainly does.

FYI,

While re-reading the protocol spec described in remote.c, I discovered
the existing 'D' (detach) command, so I'm now using 'b' instead of 'D'
for removing break/watchpoints.

> One issue with 'b' is that it's used in the sparc* stubs to set the
> baud rate of the connection.  That code has been #ifdef'd out with 
> the comment "Disabled until we can unscrew this properly", so we may
> be able to simply junk that.


	--jtc

J.T. Conklin
RedBack Networks

Re: breakpoint extension for remote protocol

[J.T. Conklin]

> > Here is the protocol elements that I'm currently working with:
> >
> >     Insert Breakpoint:     B<type>,<address>[,<length>]
> >     returns:               ??   - A cookie representing the breakpoint
> >                            EX   - breakpoint type not supported
> >                                 - no breakpoint contexts available
> >                                 - invalid/unsupported address
> >                                 - invalid/unsupported length
> 
> FYI, there is already a semi-official use of `B' as a generic remote
> breakpoint operation.  The syntax is:
> 
>     B<address>,S    Set a breakpoint
>     B<address>,C    Clear a breakpoint
> 
> When using this, GDB assumes the target can handle all breakpoints.

Umm... I checked the current (98/11/21) GDB snapshot's remote.c, all
of the sample stubs, and remote.texi and could find no evidence of a
breakpoint command, much less a 'semi-official' one.  So I went back
to a design Stu described to me some years ago as the foundation of my
current work.

I think the refined proposal I sent to the list yesterday is far
superior to the the one described above, as that would require yet
another set of commands for hardware break/watchpoints.

> With regard to the general question of extending the remote-gdb protocol
> so that it supports a generic hardware breakpoint mechanism.  I agree it
> is needed.  It is a missing part of the overall toolkit.  

> Did you know that some targets actually implement hardware
> breakpoints by poking the registers directly?

I saw that.  Yuck.


	--jtc

Re: breakpoint extension for remote protocol

[Andrew Cagney]

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

Re: breakpoint extension for remote protocol

[J.T. Conklin]

> 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

Re: breakpoint extension for remote protocol

[Stan Shebs]

   Date: Mon, 04 Jan 1999 17:19:34 -0800
   From: "J.T. Conklin" <jtc@redbacknetworks.com>

   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.

Those who study recent snapshots will notice that we are doing some
internal cleanup that will make it easier to support CPU variants
without kludging.

My general principle for this kind of thing is that GDB should be able
to support both direct manipulation of target resources, as well as
the use of a target-side agent to do the same thing.  For instance, if
you want to use hardware watchpoint registers with a JTAG/BDM setup
that has no target-side agent at all, then GDB must do the register
manipulation itself.  Conversely, when interacting with a workstation
OS, GDB must (almost) always go through the OS to be successful.

Ideally, GDB would provide internal modules for operations that may be
hardware-specific, similar to mem-break, that backend writers can use
as needed, and it should provide interfaces to them through the target
vector.  We've been very inhibited about adding to the target vector
over the past couple years, but there is really no penalty for doing
so, and with the new setup strategy, it's possible to add fields
without tracking down and modifying every target_ops in sight.  So I
expect to see more things go through the proper internal interfaces,
rather than around them.

							Stan

Re: breakpoint extension for remote protocol

[Jim Blandy]

For the record, Zdenek Radouch pointed out a while back on the
internal GDB mailing list a distinction that I liked:

There are actually three "architectures" that we care about:
  - the architecture of the processor itself
  - the ABI and calling conventions (controlled by the compiler/linker
    environment)
  - the target board architecture (excluding the CPU)

At present, we kind of smoosh them all together, which causes
confusion when someone else needs to wade into our code and
disentangle our assumptions.  We support multiple ABI's for the MIPS
and PPC (at least), and (I think???) you have to select the one you
want at configuration time (--target=powerpc-eabi, for example).  So
we are already drifting away from "generic" embedded toolchains, which
I agree is bad.

When we estimate new GDB ports, we should include time to actually
segregate those three things nicely, so that GDB could have a "set
abi" and "set board" command.  Otherwise, if GDB is really to know all
that stuff (as Stan has said it should), it's going to be a total mess.

Re: breakpoint extension for remote protocol

[Stan Shebs]

   From: Jim Blandy <jimb@cygnus.com>
   Date: 16 Feb 1999 13:49:54 -0500

   For the record, Zdenek Radouch pointed out a while back on the
   internal GDB mailing list a distinction that I liked:

   There are actually three "architectures" that we care about:
     - the architecture of the processor itself
     - the ABI and calling conventions (controlled by the compiler/linker
       environment)
     - the target board architecture (excluding the CPU)

Yes, this is a good mental model.

   At present, we kind of smoosh them all together, which causes
   confusion when someone else needs to wade into our code and
   disentangle our assumptions.  We support multiple ABI's for the MIPS
   and PPC (at least), and (I think???) you have to select the one you
   want at configuration time (--target=powerpc-eabi, for example).  So
   we are already drifting away from "generic" embedded toolchains, which
   I agree is bad.

This is a leftover from native debugging, where the configure-time
choice of host OS determines architecture and ABI.  In fact, even
CPU variants are often reduced down to a single "programmer's model"
that restricts access to some of a chip's features (like supervisor
mode :-) ).

   When we estimate new GDB ports, we should include time to actually
   segregate those three things nicely, so that GDB could have a "set
   abi" and "set board" command.  Otherwise, if GDB is really to know all
   that stuff (as Stan has said it should), it's going to be a total mess.

In general, GDB should not have to know much about specific boards;
things are simplified overall if the board support package takes care
of board idiosyncrasies, so for instance GDB can say "write memory"
and the board does one thing for flash, and something else for RAM.

ABI is clearly a weak point, and in the mercifully few cases of chips
with multiple ABIs, we do need to make the choice dynamically rather
than statically, preferably automatically by studying the code, but
with a manual "set abi" command to handle failures of automation.

Unlike with GCC, there is little or no advantage to compiling GDB's
target knowledge in at build time.  So we should be moving towards
making it more dynamic overall.

							Stan

Re: breakpoint extension for remote protocol

[J.T. Conklin]

>>>>> "shebs" == Stan Shebs <shebs@cygnus.com> writes:
jimb>  There are actually three "architectures" that we care about:
jimb>		- the architecture of the processor itself 
jimb>		- the ABI and calling conventions (controlled by the
jimb>		  compiler/linker environment)
jimb>		- the target board architecture (excluding the CPU)

I think the second point could be further subdivided.  For the most
part, GDB only cares about the calling conventions.  But in some
cases, for example with setjmp()/longjmp(), it wants to know the
internals of the implementation.  There is no guarentee that my
setjmp()/longjmp() implementation is going to store registers in
the same order as anyone elses.

I'm not quite sure what is meant by target board architecture,
hopefully whatever back end GDB uses (the remote protocol, a ROM
monitor, etc) abstracts and isolates it from the target board.

shebs> Yes, this is a good mental model.

jimb> At present, we kind of smoosh them all together, which causes
jimb> confusion when someone else needs to wade into our code and
jimb> disentangle our assumptions.  We support multiple ABI's for the
jimb> MIPS and PPC (at least), and (I think???) you have to select the
jimb> one you want at configuration time (--target=powerpc-eabi, for
jimb> example).  So we are already drifting away from "generic"
jimb> embedded toolchains, which I agree is bad.

I think it's not so much drifting away from "generic" toolchains.  The
infrastructure for generic toolchains wasn't/isn't in place, and it is
a lot of work to retrofit.  

It used to be much worse.  When I joined Cygnus, I believe there were
several m68k toolchains --- as GDB backend and newlib target support
for the various eval boards were separate configs.

shebs> This is a leftover from native debugging, where the
shebs> configure-time choice of host OS determines architecture and
shebs> ABI.  In fact, even CPU variants are often reduced down to a
shebs> single "programmer's model" that restricts access to some of a
shebs> chip's features (like supervisor mode :-) ).

And MMU and other system registers, etc.

jimb> When we estimate new GDB ports, we should include time to
jimb> actually segregate those three things nicely, so that GDB could
jimb> have a "set abi" and "set board" command.  Otherwise, if GDB is
jimb> really to know all that stuff (as Stan has said it should), it's
jimb> going to be a total mess.

And also so you have a complete product in the end.  For example,
there've been many new GDB ports done, but there haven't been many new
stubs.

shebs> In general, GDB should not have to know much about specific
shebs> boards; things are simplified overall if the board support
shebs> package takes care of board idiosyncrasies, so for instance GDB
shebs> can say "write memory" and the board does one thing for flash,
shebs> and something else for RAM.

Agreed, write protected RAM, EEPROM, flash, banked memory, etc. should
all be handled by the code in the stub that handles the 'write memory'
command.  Using a vendor-supplied ROM monitor might require additional
knowlege by GDB about the target and "helper" routines in the
application.  Bleh.  That's too ugly to think about.

	--jtc

-- 
J.T. Conklin
RedBack Networks

breakpoint extension for remote protocol

[J.T. Conklin]

I've been tasked to add support for hardware watch/breakpoints over
the remote protocol.  

This is what I'm thinking so far: A create breakpoint command would
insert a breakpoint insn or set the appropriate debug registers.  A
cooresponding delete breakpoint command would remove a breakpoint.

Having stubs manage their own breakpoints may even be adventageous for
systems without hardware breakpoints.  As GDB inserts breakpoint insns
directly in the text segment, it requires the text segment to be read/
write.  Errors that would ordinarily cause an exception could pass
unnoticed.  The mem write command could be modified to write enable
the page, copy the data, and then write protect it again; but doing
those protection modifications only when breakpoints are inserted and
removed protects the user from inadvertantly using GDB to modify read
only data.

This of course, would require the stubs to keep track of more
information.  In many cases allocating breakpoint contexts dynamically
would be impossible or undesirable (it is likely that you couldn't use
the same dynamic memory allocator as the rest of the system (if indeed
such a facility was available) as it wouldn't be safe to use in an
interrupt/exception context).  As such, the protocol will have to have
a mechanism to indicate that all available breakpoints have been
allocated.  This is probably not much of a concern, since ROM monitors
and hardware watch/breakpoint registers have similar constraints.  I'd
like to not limit the number of contexts to a fixed number, as some
systems/debugging situations may need many more than others.

Here is the protocol elements that I'm currently working with:

    Insert Breakpoint:	   B<type>,<address>[,<length>]
    returns:		   ??	- A cookie representing the breakpoint
			   EX	- breakpoint type not supported
				- no breakpoint contexts available
				- invalid/unsupported address
				- invalid/unsupported length

    Remove Breakpoint:	   D<cookie>
    returns:		   OK	- breakpoint removed
			   EX	- breakpoint <cookie> not found


    <type>		   'r', 'w', 'x' for read, write, or execute.
    <address>		   A target address
    <length>		   1, 2, or 4; number of bytes for read or 
			   write watchpoint.

When the target is started (step, continue), the stub is responsible
for installing breakpoints instructions.  Likewise, when the stub
regains control, it is responsible for removing breakpoints.

	--jtc

Re: breakpoint extension for remote protocol

[Greg McGary]

"J.T. Conklin" <jtc@redbacknetworks.com> writes:

> I've been tasked to add support for hardware watch/breakpoints over
> the remote protocol.  

The remote stub I implemented for Ascend routers manages breakpoints,
and doing so cuts way down on communication overhead--I recommend it.
Keep in mind that doing so makes the stub stateful, so you must now
pay attention to detecting and discarding duplicates.  It's not
generally an issue for point-to-point connections over serial, but we
also use UDP as a transport, and across multiple hops it's possible
for gdb to timeout and retransmit a breakpoint set or clear command,
and if the retransmit came because of delayed rather than non
delivery, the stub will receive both.  When two breakpoint-set
commands arrive, was the second a duplicate, or did the user set two
BPs at the same address?  It makes most sense to maintain a reference
count for each address with a BP on the gdb host side's cache, and
maintain only a simple list of BP addresses in the stub's cache.  The
gdb host issues the remote BP clear command only when the gdb host's
reference count reaches 0, and issue the remote BP set command only on
the first BP set at an address.