Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Batchelor <A.C.Batchelor-99@student.lboro.ac.uk>
To: ramana.radhakrishnan@codito.com
Cc: GDB Newsgroup <gdb@sources.redhat.com>
Subject: Re: Protocol Translation (Apologies for LONG email)
Date: Wed, 11 Feb 2004 22:12:00 -0000	[thread overview]
Message-ID: <1076537577.1122.894.camel@And.Linux> (raw)
In-Reply-To: <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


  parent reply	other threads:[~2004-02-11 22:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-11 13:33 Ramana Radhakrishnan
2004-02-11 13:48 ` Bill Gatliff
2004-02-11 22:12   ` Andrew Batchelor
2004-02-11 22:12 ` Andrew Batchelor [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-02-11 13:11 Andrew Batchelor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1076537577.1122.894.camel@And.Linux \
    --to=a.c.batchelor-99@student.lboro.ac.uk \
    --cc=gdb@sources.redhat.com \
    --cc=ramana.radhakrishnan@codito.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox