This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Protocol Translation (Apologies for LONG email)
- From: Andrew Batchelor <A dot C dot Batchelor-99 at student dot lboro dot ac dot uk>
- To: ramana dot radhakrishnan at codito dot com
- Cc: GDB Newsgroup <gdb at sources dot redhat dot com>
- Date: 11 Feb 2004 22:12:54 +0000
- Subject: Re: Protocol Translation (Apologies for LONG email)
- References: <35988.203.199.140.162.1076507136.squirrel@webmail.codito.com>
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