From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27251 invoked by alias); 11 Feb 2004 13:48:55 -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 27204 invoked from network); 11 Feb 2004 13:48:54 -0000 Received: from unknown (HELO saturn.billgatliff.com) (209.251.101.200) by sources.redhat.com with SMTP; 11 Feb 2004 13:48:54 -0000 Received: from billgatliff.com (bb-203-125-70-61.singnet.com.sg [203.125.70.61]) by saturn.billgatliff.com (Postfix) with ESMTP id 264784E0004; Wed, 11 Feb 2004 07:48:52 -0600 (CST) Message-ID: <402A32C3.1000506@billgatliff.com> Date: Wed, 11 Feb 2004 13:48:00 -0000 From: Bill Gatliff User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 MIME-Version: 1.0 To: Andrew Batchelor Cc: GDB Newsgroup Subject: Re: Protocol Translation (Apologies for LONG email) References: <35988.203.199.140.162.1076507136.squirrel@webmail.codito.com> In-Reply-To: <35988.203.199.140.162.1076507136.squirrel@webmail.codito.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00106.txt.bz2 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 > >