Re: remote debug of 68EZ328

[Stan Shebs <shebs at cygnus dot com>]

   From: David Williams <davidwilliams@ozemail.com.au>
   Date: Thu, 2 Dec 1999 11:21:31 +1100

   I am still trying to ramp up on required knowledge to tackle this...

   1. As far as I can tell, the remote protocol specifies communications 
   between a stub on the target system and GDB on host system. I assume that 
   there is some 68K specific code as part of GDB that communicates to stub on 
   target system - I am a little cloudy on this and would appreciate some 
   clarification.

Yes, GDB has m68k-specific code that describes the architecture
in a somewhat abstract way, and only in as much detail as the debugger
needs.  So for instance, there are bits saying that d0 is a 32-bit
register, a6 is the frame pointer, fp0 contains floats, etc.  There
are also procedures to do things like decoding frames.  All of this
code is common to all m68k systems, whether they're Apollos, Sun-3s,
Palms, whatever.

The remote protocol and its implementation are very generic.  The
protocol is just a set of commands, like "$g#67", which says to
deliver all the registers.  The size of the response is very different
from one system to another, but GDB just hopes for the best :-) and
dumps the blob of data into the array of registers.  Once GDB has
acquired some register and memory data via the generic protocol, it
puts its m68k-specific code to work analyzing it, eventually resulting
in a reconstruction of your program's state.

So the purpose of your stub is simply to report program state and to
obey the commands (packets) sent to it by GDB.  Since GDB has no other
means to contact the target system except the stub, it will pretty
much believe what your stub tells it.  This suggests interesting
tricks that you can do - for instance, you could notice that a memory
write seems to be the depositing of a breakpoint instruction, and do
something else, like set a hardware breakpoint.  As long as you're
telling GDB believable things, it will go along.

   2. Looking through the procotol & source for 68K-stub leads me to believe 
   that the 68K stub (and possibly all stubs) do not support hardware 
   breakpoints - they work by assuming code is running is RAM and op-code can 
   be substituted for trap instructions. Is this correct? If so then I cannot 
   use the remote protocol and a stub to support hardware breakpoints. What 
   other method is best. (I have received some responses to previous queries 
   on this subject but I still dont get it!)

We've recently defined a 'Z' packet that is for the purpose of setting
hardware breakpoints.  The generic m68k stub in the sources doesn't
use it, because any such code would be very specific to particular
systems.  As you may have noticed, the stub file is public domain, not
even GPLed, because we want everybody to modify stubs so they'll fit
properly into the target system.  As long as you conform to the
established protocol as defined in the manual, you can do whatever you
want.

   3. Some people have mentioned insight to me. The suggestion is the Insight 
   may have slightly different (and possible later) sources for GDB component. 
   Is this true? I am interested in using a GUI with GDB and this sounds good. 
   My specific problems are that I am currently using win95 as my development 
   platform (yes I know) and dont know how this will affect development of 
   changes required to GDB (Insight).

Since you're already used to crashes, you won't be any worse off than
you are now... :-) Insight is just a tcl GUI extension to basic GDB.
The snapshot sources on sourceware are synced with the basic GDB
sources available at the same place, so you can use either as you
prefer.  Building everything from scratch using cygwin on W95 usually
takes so long that something crashes before it finishes, but if you
reboot and continue building, you can eventually get to a working GDB.

								Stan