Re: Protocol Translation (Apologies for LONG email)

Re: Protocol Translation (Apologies for LONG email)

[Ramana Radhakrishnan]

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

Re: Protocol Translation (Apologies for LONG email)

[Bill Gatliff]

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

Re: Protocol Translation (Apologies for LONG email)

[Andrew Batchelor]

Hi Bill,

Thanks for your reply...

On Wed, 2004-02-11 at 13:48, Bill Gatliff wrote:
> 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.

Hmmm, good idea, I'd not thought of that.  I've not really looked at the
gdbserver code, so I think I'll have a dig around in the morning.  It
sounds like what I'm after...

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

I'm not sure I understand you here, "parse a configuration file"?

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

Do all GDB messages go via the gdbserver?

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

That's a plus.  I'm still flip-flopping between actually adding-IN to
the GDB code or (like this) adding-ON to it.

Thanks again for your help.


Andrew

Re: Protocol Translation (Apologies for LONG email)

[Andrew Batchelor]

Hi Ramana,

Thanks for your reply...

On Wed, 2004-02-11 at 13:45, Ramana Radhakrishnan wrote:
> 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.

Ah, I see.  The RV-ICE box can be reached through the ethernet, but it
has to be setup and initialised before any communication can occur with
the target.  With regard to ser-tcp.c, I was wondering whether I could
just point the functions in '_initialize_ser_tcp' to my own translating
functions, e.g.

  ops->readchar = rvmsg_2_rsp_read;
  ops->write = rsp_2_rvmsg_write;

But I see what you're saying.

> 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 I'd have a file called remote-<something>.c (or would add to
remote.c) containing all the relevant functions for RV-MSG communication
(similar to the cisco stuff).  So I could have my own:

	remote_rvmsg_open,
	remote_rvmsg_close,
        .....
	remote_rvmsg_fetch_registers functions etc.

And would only need to concern myself with getting the relevant info
back to GDB via the "serial_write" function (Line 5747, remote.c)?

I'd then have to link all the used functions via something like:

	remote_rvmsg_ops.to_open = remote_rvmsg_open;
	remote_rvmsg_ops.to_close = remote_rvmsg_close;
	.....
	remote_rvmsg_ops.to_fetch_registers =
			remote_rvmsg_fetch_registers,  etc.

And then push the newly made target into GDB before using it:

	push_target (&remote_rvmsg_ops);

Does this sound (very) roughly correct?

> So option 1 is the correct one. IMO option 2 does not seem valid.

Okay, thank you for all the info.  What do you think of Bill Gatliff's
idea of creating my own gdbserver-type proxy program?  How do you think
it compares?


Andrew

Protocol Translation (Apologies for LONG email)

[Andrew Batchelor]

Hello,

Sorry, it's been quite a while since I emailed in about this.  Thanks to
everyone who has emailed me about it - on the whole, they've been very
helpful.  

For those of you who don't know:  I'm writing a Protocol Translator for
GDB's RSP (Remote Serial Protocol) to ARM's RV-MSG Protocol (RealView
Messaging).  It will allow, for example, GDB to connect to a target via
an RV-ICE device.

The translation bit needs to take place on the host (GDB) side of the
system as I can't really touch the RV-ICE/Target side.  This means no
stub file.

As it stands at the moment there are two basic ways I'm thinking of
going about this:

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.

This seems to me to be the most plausible, but what I really need to
know from those of you with a decent depth of knowledge of GDB is:

Which of these ways do you think is the most reasonable?
Which has the simplest implementation? (Bearing in mind all changes on
the GDB side)
Are there any areas you think I might have problems with?

Any help or advice you could offer would be much appreciated.

Thanks.


Andrew