This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 5/8] Doc for agent
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