Re: breakpoint extension for remote protocol

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

GDB: one version for all targets

[Brendan Simon]

From some of the discussions on this list, I have interpretted that GDB may
be moving to one version that can dynmically detect the CPU target and ABI
type.  A manual setting for these is provided as a fallback if autodetection
fails.

Does this mean there would only be one GDB that would cater for all targets.
eg. i386, powerpc, m68k, etc ?

This sounds like a fantastic idea and I look forward to such a versatile
debugger.
Does anyone know when this is likely to be available ?

I assume the correct simulator would be called based on the above settings.

To reduce diskspace, would it be possible to have the supported targets and
ABI types as some kind of shared library or plug in module ?


Brendan Simon.
From devnull@gnu.org Thu Apr 01 00:00:00 1999
From: "Joel N. Weber II" <devnull@gnu.org>
To: gnu-prog@gnu.org
Subject: ftp.gnu.org redisorganization
Date: Thu, 01 Apr 1999 00:00:00 -0000
Message-id: <199901080426.XAA08145@melange.gnu.org>
X-SW-Source: 1999-q1/msg00015.html
Content-length: 1058

I have redisorganized ftp.gnu.org so that there is now a directory for
every package (although at the moment, the emacs lisp manual, the
emacs lisp intro, leim, and elib all exist in the emacs directory; we
may rearange that).  For example, there exists a directory at
ftp://ftp.gnu.org/gnu/emacs which contains various versions of emacs.

Someone had suggested that we should also make
ftp://ftp.gnu.org/gnu/emacs/emacs.tar.gz a symlink to the .tar.gz of
the current version.  We rejected this possibility; if we do this,
people will end up with .tar.gz files on their local disks that lack
the version number.

If people notice problems with how the redisorganization was done,
please let me know.

We are now willing to make links to these directories from webpages
under http://www.gnu.org/software ; so please feel free to update your
web pages (or create web pages for your packages, if you haven't
already!).  If we haven't given you more specific instruction on what
to do to submit new or changed webpages, please mail them to
webmasters@gnu.org.

Re: GDB: one version for all targets

[Stan Shebs]

   Date: Wed, 17 Feb 1999 13:25:21 +1100
   From: Brendan Simon <brendan@dgs.monash.edu.au>

   >From some of the discussions on this list, I have interpretted that GDB may
   be moving to one version that can dynmically detect the CPU target and ABI
   type.  A manual setting for these is provided as a fallback if autodetection
   fails.

   Does this mean there would only be one GDB that would cater for all targets.
   eg. i386, powerpc, m68k, etc ?

Yes, that ought to be possible some day.  It would it to be like a config
option, a la BFD's --with-targets=all.

   This sounds like a fantastic idea and I look forward to such a versatile
   debugger.
   Does anyone know when this is likely to be available ?

It's going to be awhile.  This is more of a direction, not a scheduled
commitment, and availability is going to be depend on how many people
actually work on this.  Can't depend on Cygnus to do it all, since among
other things we don't even have all the targets inhouse to test.

   I assume the correct simulator would be called based on the above settings.

The existing builtin simulators all present the same API, and thus are
not set up to link in more than one.  However, it would be sensible to
build sims into gdbserver and have a single debugger able to talk with
any of the servers.

   To reduce diskspace, would it be possible to have the supported targets and
   ABI types as some kind of shared library or plug in module ?

That would certainly be a good way to implement.  In practice, most
users don't care, because it primarily matters to embedded developers
using multiple architectures at once.  It's going to be a long time
before a single GDB can be both a native x86 Linux and PA HP-UX debugger! :-)

The real value in this sort of change is for things like
multiprocessor cross-debugging, which is an exotic activity nowadays,
but I expect it will become more common in the future.

								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