This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdbserver tracepoint support (from Project Ideas page)
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...
>
>
>
>