Re: [patch 5/8] Doc for agent

[Pedro Alves <palves@redhat.com>]

On 02/10/2012 04:18 PM, Yao Qi wrote:

> 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.

Nope, that's not true at all.  Several architectures can run in
different modes (x86 32-bit/64-bit; arm/thumbx big/little/mixed; mips; ppc, etc.).
Several architectures have more than one ABI.  We can have e.g., a 64-bit
gdbserver controlling a 32-bit process on x86.  You can have a gdbserver controlling
an inferior that's running a different endianness on some machines.

The current IPA has the limitation that fast tracepoints only work if the
inferior has the same arch/abi as gdbserver.  If we're adding a new IPC,
and an IPA v2, let's not repeat the mistake.

>   #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.

Traceframe data is a different matter.  We can open a shared
memory channel for those, for example.  Note traceframes have
a fixed and defined format (so we have the tfile target).

>   #3.  be efficient.  binary presentation is quite compact, and
> memcpy-like operation is efficient as well.

It also doesn't work.  See above.

>   #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.

The command channel is not the fast path.  You don't need, and shouldn't
be micro-optimizing it.

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

-- 
Pedro Alves