Re: gdbserver tracepoint support (from Project Ideas page)

[Michael Snyder <msnyder@specifix.com>]

On Wed, 2008-02-20 at 17:35 -0800, Doug Evans wrote:
> 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 always thought that one interesting implementation for
tracepoint data collection would be as a shared library that
the child program could be linked with at runtime -- in the
manner of libsegfault, so that you don't have to change the
child program at all.  In that way, it would share address
space and only incur the cost of a signal handler, not a
full context switch (or even a thread context switch).

Is that something like your thinking?