Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <yao@codesourcery.com>
To: Pedro Alves <palves@redhat.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [patch 5/8] Doc for agent
Date: Fri, 10 Feb 2012 16:18:00 -0000	[thread overview]
Message-ID: <4F354343.3060302@codesourcery.com> (raw)
In-Reply-To: <4F353146.3020504@redhat.com>

On 02/10/2012 11:01 PM, Pedro Alves wrote:
> Re. "control agent by commands".  So you're planning on making the agent speak
> some other command set other than RSP?  I'd think that making it talk exactly
> RSP would be the best, since #1, you need some kind of command set anyway;
> #2, the agent should be able to support debugging (stepping, breakpoints,
> etc.) without gdbserver involved, and for that you'd want to support
> the RSP anyway so that GDB can connect.  Unless you're coming up with some
> new rpc/marshaling protocol that's clearly superior to RSP?

[I planed to discuss on the choice on protocols when this series go
in, because this series of patches just set up a communication
channel, but protocol is not involved this patch series.]

The protocol between agent and GDB/GDBserver is different from RSP.
This protocol is composed by a set of commands.  In each command,
there is an opcode (in ascii) and oprand (in binary).  When sending
a command, we serialize parameters into command buffer, and in agent
side, we de-serialize parameters out of command buffer.  The process
of serialize/de-serialize is quite specific to each command.  Taking
command `installing tracepoint' for example, the parameter is an
instance of tracepoint.  We copy the instance of tracepoint, along
with objects it references to, to command buffer, and in agent, we
build tracepoint instance from command buffer.  It is similar to RPC
call.

The reasons for this kind of design are,

  #1.  agent, inferior and debugger (GDB or GDBserver) are running
on the same machine, so protocol doesn't to have to handle machine
difference, such as endianess, word size, etc.  Binary copy should
work fine.
  #2.  avoid to transform data twice.  When data is ready, say
tracepoint, it is efficient to copy data directly, rather than
transforming to some format, and agent will transform it back later.
  #3.  be efficient.  binary presentation is quite compact, and
memcpy-like operation is efficient as well.
  #4.  as close to raw data as possible.  agent is running in the
same process with inferior, and the same machine with debugger.  The
process of protocol is like copying parameter from one process to
another.  We don't have to transform the format of raw data.

It is a piece of new work, I am open to comments.

-- 
Yao (齐尧)


  reply	other threads:[~2012-02-10 16:18 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-23 13:37 [patch 0/8] GDB/GDBserver talks with agents Yao Qi
2012-01-23 13:48 ` [patch 1/8] Generalize interaction with agent in gdb/gdbserver Yao Qi
2012-01-30 11:25   ` Yao Qi
2012-02-09 19:21   ` Pedro Alves
2012-02-14  2:41     ` Yao Qi
2012-02-14 10:16       ` Pedro Alves
2012-01-23 13:50 ` [patch 2/8] Add to_use_agent in target_ops Yao Qi
2012-02-09 19:36   ` Pedro Alves
2012-01-23 13:54 ` [patch 3/8] Command `set agent on|off' Yao Qi
2012-01-23 17:14   ` Eli Zaretskii
2012-01-24  0:28     ` Yao Qi
2012-01-24  5:54       ` Eli Zaretskii
2012-01-26  1:32         ` Yao Qi
2012-02-09 20:19   ` Pedro Alves
2012-01-23 13:58 ` [patch 4/8] `use_agent' for remote and QAgent Yao Qi
2012-01-23 17:17   ` Eli Zaretskii
2012-01-26  2:17     ` Yao Qi
2012-01-26 17:43       ` Eli Zaretskii
2012-02-09 19:55   ` Pedro Alves
2012-01-23 14:03 ` [patch 5/8] Doc for agent Yao Qi
2012-01-23 18:12   ` Eli Zaretskii
2012-01-24  0:51     ` Yao Qi
2012-01-24  8:04       ` Eli Zaretskii
2012-01-26  1:53         ` Yao Qi
2012-01-26 17:15           ` Eli Zaretskii
2012-02-09 19:55   ` Pedro Alves
2012-02-10 13:30     ` Yao Qi
2012-02-10 15:01       ` Pedro Alves
2012-02-10 16:18         ` Yao Qi [this message]
2012-02-10 16:28           ` Pedro Alves
2012-02-23  7:51             ` Yao Qi
2012-02-23 19:50               ` Pedro Alves
2012-01-23 14:07 ` [patch 6/8] Agent's capability Yao Qi
2012-01-24  3:49   ` Yao Qi
2012-02-09 20:09   ` Pedro Alves
2012-02-10 12:25     ` Yao Qi
2012-02-10 12:37       ` Pedro Alves
2012-02-10 13:07         ` Yao Qi
2012-01-23 14:29 ` [patch 7/8] Agent capability for static tracepoint Yao Qi
2012-02-09 20:13   ` Pedro Alves
2012-02-10 14:29     ` Yao Qi
2012-02-10 14:56       ` Pedro Alves
2012-01-23 16:03 ` [patch 8/8] Control agent in testsuite Yao Qi
2012-02-09 20:16   ` Pedro Alves
2012-02-05  4:32 ` [ping] [patch 0/8] GDB/GDBserver talks with agents Yao Qi
2012-02-09 19:02 ` Pedro Alves

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=4F354343.3060302@codesourcery.com \
    --to=yao@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.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