This is the mail archive of the
mailing list for the GDB project.
Re: gdbserver tracepoint support (from Project Ideas page)
On Thu, Feb 21, 2008 at 11:45 AM, Michael Snyder <email@example.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