Re: Protocol Translation (Apologies for LONG email)

[Bill Gatliff <bgat@billgatliff.com>]

Andrew:


Could you make a gdbserver-like proxy utility, that would launch before 
gdb and listen on a port on localhost?  Gdb would then connect to that 
port with RSP (or RDI or whatever), and you could translate the incoming 
messages to whatever protocol you needed on the ICE end.

Your server program could parse a configuration file, which might 
contain instructions to download the application to the target before 
gdb connects, or other housekeeping matters.

Once connected, you could use gdb's "maintenance" commands to send 
out-of-band messages for the things that don't translate well between 
RSP and your target protocol.

This is not unlike how gdbserver, the BDI2000, and some versions of the 
Wiggler work, and it wouldn't require modification of a single line of 
gdb source code.

Just my $0.02USD.


b.g.


Ramana Radhakrishnan wrote:

>>Method 1) Add a new target, e.g. remote-rvi.c or something.
>>
>>There's nothing wrong with adding a new target except I can see myself
>>running into problems with the functions I've coded.  I need to connect
>>to the RV-ICE in a certain way and also to build/send/receive/decode the
>>RV-MSG messages in a certain way.  As far as I can see, this is simply
>>not directly compatible with any of the GDB functions because my
>>remote-rvi.c file would need complete control to:
>>
>>	Establish a connection to the RV-ICE.
>>	Connect/Disconnect to the target through the RV-ICE.
>>	Download a program through the RV-ICE to the target.
>>
>>Can I have this control from just one remote-rvi.c (type) C file?
>>
>>It would also mean wading through the C hierarchy in order to determine
>>which GDB functions I need to accomplish the various commands.  This
>>looks like a lot of work at this stage as (respectfully) the development
>>documentation for this type of thing is poor, and I'm having to figure
>>it out by trawling through the C structure, to see where various
>>functions are actually defined in order to work out what they're
>>actually doing.
>>
>>In addition to this, there is no real protocol translation going on -
>>more "C-function" translation which is not really the idea.  Anyway,
>>what are your thoughts on this one?
>>
>>Method 2) Use 'remote tcp' with some kind of switch and
>>          capture/translate the RSP messages before they go out on the
>>          Ethernet.
>>
>>I'd need to find out where exactly GDB constructs it's RSP message
>>before it sends it out down the Ethernet and capture it before it goes.
>>I think this would involve something like checking the command line
>>switch and changing the read/write functions in ser-tcp.c and/or
>>ser-unix.c to write/read their messages to/from my own translation
>>function.
>>    
>>
>
>ser-tcp , ser-unix.c just add the communication interfaces to gdb
>depending on the underlying communication to the debug monitor . I assume
>that your RVICE box can be reached through the ethernet / serial cable. So
>any communication based stuff is already in there. What you need to be
>doing is to add your own target implementing the members of the target
>structure that rv-ice will support for you .
>
>
>For e.g. if you look at remote.c you can see functions like
>
>remote_insert_breakpoint in remote.c which actually constructs the packet
>to be sent out and then calls the underlying putpkt to do the actual
>communication to the target. What you might consider doing is just simply
>set up the remote protocol details for your RVICE ? The protocol details
>like the command to insert a breakpoint, etc. etc.
>
>So option 1 is the correct one. IMO option 2 does not seem valid.
>
>
>HTH
>
>cheers
>Ramana
>
>
>
>----
>Ramana Radhakrishnan
>GNU Tools
>Codito Technologies
>  
>