From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16694 invoked by alias); 11 Feb 2004 13:11:36 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16675 invoked from network); 11 Feb 2004 13:11:35 -0000 Received: from unknown (HELO weed.lut.ac.uk) (158.125.1.226) by sources.redhat.com with SMTP; 11 Feb 2004 13:11:35 -0000 Received: from [82.2.209.18] (helo=And.Linux) by weed.lut.ac.uk with esmtp (Exim 4.30) id 1Aqu9O-0005oP-36 for gdb@sources.redhat.com; Wed, 11 Feb 2004 13:11:34 +0000 Subject: Protocol Translation (Apologies for LONG email) From: Andrew Batchelor To: GDB Newsgroup Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 11 Feb 2004 13:11:00 -0000 Message-Id: <1076505117.1123.188.camel@And.Linux> Mime-Version: 1.0 X-Scan-Signature: e74274aa02ab1ab1b23f1f3321eaa89f X-SW-Source: 2004-02/txt/msg00104.txt.bz2 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