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] |
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