This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Tracepoints (and python)
- From: Marc Brünink <marc at nus dot edu dot sg>
- To: Doug Evans <dje at google dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb <gdb at sourceware dot org>
- Date: Fri, 11 Jan 2013 15:29:22 +0800
- Subject: Re: Tracepoints (and python)
- References: <464A745A-AA80-4485-820E-64C4D01A270C@nus.edu.sg> <87k3scn69b.fsf@fleche.redhat.com> <CADPb22Rf9wS8ah8it956d2jcWKpLwNEbZz7aWtDb8cJkJ4Uf6Q@mail.gmail.com> <87k3rv5wab.fsf@fleche.redhat.com> <CADPb22Ss8KfBBxnVg4fgjEH_m_+XOsFRjiNY2V6HPK5n3BG3fw@mail.gmail.com>
On Jan 3, 2013, at 1:44 AM, Doug Evans wrote:
> On Wed, Jan 2, 2013 at 10:28 AM, Tom Tromey <tromey@redhat.com> wrote:
>> Marc> 1. Is there any technical reason why tracing is only possible on
>> Marc> remote targets? Or is is "just" not implemented for anything else.
>>
>> Tom> I think the only reason is that nobody has done it.
>>
>> Doug> This is part of gdb/gdbserver feature parity desires right?
>>
>> It is on the list on the wiki, but I think just to mention it as a
>> difference. We (meaning Red Hat) plan to tackle most of the items on
>> that list, but I don't think this is one we are going to do.
>
> [Sorry for the resend, previous one got sent as text/html.]
>
> Thanks.
>
> For clarity's sake for Marc,
> what's needed isn't so much an implementation as a (pretty
> significant) refactor.
Interesting. Actually I am trying to implement a rudimentary application tracer using the python interface. So far I have simply used breakpoints. It works like a charm but is obviously very slow. Thus, I want to switch to tracepoints. Having access to tracepoints during native debugging would be nice but is not necessary. This is a point for my personal wish list.
Another issue is the trace buffer. It would be nice to get a notification as soon as the trace buffer is full. Currently gdbserver does not sent one (assuming gdb is connected), does it?
Marc