This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Protocol Translation (Apologies for LONG email)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]