Re: gdbserver tracepoint support (from Project Ideas page)

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

On Thu, Feb 21, 2008 at 11:45 AM, Michael Snyder <msnyder@specifix.com> wrote:
>  > 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?

That is one way to implement it, my "way cool" comment had in mind a
more efficient implementation (albeit more complex too).  I don't have
any numbers so I'm not advocating one over the other.

btw, is there any existing implementation anywhere for a remote
target?  Something in libgloss or rda (redhat debug agent?) or some
such?