This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 5/8] Doc for agent


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 (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]