This is the mail archive of the gdb-patches@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]

Remote serial protocol

Dear GDB maintainer:

If what I'm asking is described somewhere, please just point it to me.
I've looked at Deja News and gdbint.info.

For remote debugging, I looked at remote.c.  We are trying to use the
GDB remote serial protocol, perhaps extending it, to satisfy something
GDB wasn't quite designed to do: automated testing.  Since we work in
the embedded environment, there are a few features that are missing in
the protocol:

    - There is no way to address the I/O space.
    - Many of the peripheral devices care whether it is a 8-, 16-bit, or
      whatever access.  The "m" and the "M" command does not facilitate
      that.  I understand that for application debugging, it really
      doesn't matter how the values get into memory.
    - For background debugging (I believe GDB wasn't designed to do
      this), we need a way to do a set of commands in an atomic fashion.
      Many peripheral devices have states, so we cannot allow any
      interruption.  For example, one sometimes has do a write and then
      a read just to get the status out.  For automated testing, the
      software needs to run at full speed and cannot be stopped.

At first, I thought I can use the extended remote protcol, i.e., the "!"
command, but it looks like it is for gdbserver to fork off another
process.

So, what is the proper way of extending the GDB remote serial protocol?

I understand that if we extend the protocol, we have to enhance the
debug stub.

Thanks.

Jim

-----
Jim Sung <jsung@rcnets.com>               (619)450-3370 x1219
RC Networks                          Fax: (619)450-3369
Flanders Dr., Suite 212
San Diego, CA  92121