On Wednesday 06 August 2008 21:38:33 TriKri wrote: > Charles Manning-2 wrote: > > The easiest way is to make a server that conforms to the gdb remote > > protocol. > > > > From the gdb side you connect via: > > > > (gdb) target remote host:1234 > > > > where host and 1234 specify where the server is. It is common to run the > > server on the same host as gdb, making the host localhost. > > > > The server converts the gdb remote protocol into calls to your probe > > library. > > Hello CHarles! > > What kind of server you mean, what purpose will it serve? Do you have any > particular server application in mind? Please explain, cause I don't really > understand how you mean I should set up a server. > > Charles Manning-2 wrote: > > There are numerous examples, particularly for ARM. Check out openocd at > > http://openocd.berlios.de/web/ this will show you the structure and > > protocol > > handling for a server. > > > > -- CHarles > > I checked out OpenOCD, but I didn't find anything about how it worked. Do > you mean I should download and take a look at the source code?
A googling for gdb remote might get you off on the right foot. THe protocol is defined here: http://sourceware.org/gdb/current/onlinedocs/gdb_33.html#SEC691 The gdb remote protocol is designed to allow gdb to send debugging commands to a remote machine that is running a gdb server (see gdbserver). But since the protocol just communicates over tcpip, you can run the server anywhere on the network, including even on the debugging host, as is typically done with openocd (there is nothing stopping you run openocd on one PC and doing gdb from another). The way you run openocd (from a local host) is as follows: 1) In one terminal window, start openocd. This is a server application that waits for gdb to connect to it. gbd then sends it debug commands which it then translates into probe commands. The probe might be a USB device or whatever. 2) In another window start gdb. Set the target to point to the openocd server (eg. target remote localhost:1234). gdb now sends debbug commands to openocd which it then sends to the probe. Some probes such as the bdi2000 are connected directly to ethernet and directly communicate via the remote protocol. In other words, the brobe itself runs the server. The reason I suggest openocd is that it really has three parts to it: 1) gdb server stuff (runs the server and parses/formats gdb remote commands/responses). 2) ARM specific stuff 3) Probe specific stuff You could extend this by adding the MIPS stuff + your probe alongside the ARM stuff. ALternatively you might just use it for inspiration.
