Re: gdbserver tracepoint support (from Project Ideas page)

["Doug Evans" <dje@google.com>]

On Wed, Feb 20, 2008 at 5:06 PM, Michael Snyder <msnyder@specifix.com> wrote:
>  When you say "[not] much benefit to implementing tracepoints
>  natively", do you mean "as opposed to just using gdbserver
>  or equivalent"?

Not precisely.  To be honest I was hedging my bets because I've kinda
thought tracepoints would find more use too, and given that there
isn't yet support in gdbserver or native, I was wondering if there was
a sufficient reason for not doing it that I was overlooking.  Part of
the initial reason for implementing them was to avoid transmitting
packets back and forth at each tracepoint.  That reason doesn't really
apply to a native implementation but the process switching to
implement this in ptrace (for linux) is a non-trivial intrusion for
many apps (as it will be in gdbserver too), so maybe that's why it
hasn't been implemented.  A hybrid approach would be way cool (i.e.
instrumenting the target program so tracepoints didn't stop the
program even when running natively - this is where remote targets have
an advantage, the stub is already in the same address space and
process - but that ups the complexity a wee bit).

> I've given thought to the issue, and I think Jim Blandy has
>  as well.  Not enough thought to make a very complete picture...
>
>  I think it would be useful, but then, I've always thought
>  tracepoints would find more use than they seem to have in
>  practice...
>
>
>
>