This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tracepoints (and python)

On Thu, Dec 20, 2012 at 10:32 PM, Tom Tromey <> wrote:
>>>>>> "Marc" == Marc Brünink <> writes:
> 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.
> I think the only reason is that nobody has done it.
> Marc> 2. Anyone working on making tracepoints available to the python
> Marc> interface? Any pitfalls to expect?
> Nobody has worked on this.
> I wouldn't predict any particularly tricky problems, at least not for
> representing the tracepoints themselves.  I'm less sure about
> representing the trace state.

I wrote some python code with tracepoint to parse the traceframe from
target (my target is KGTP).  You can get a example in

I have 3 issues with it:
1. Not sure about upstream, but when I use it, it is hard to setup
tracepoint action with python.  How I handle it is write tracepoint
and action to a GDB source file and call soure command in python

2. Another is the performance issue.  If you have a lot of traceframe
need to be analysed by python,  you will get it.  And actually, the
url that I posted is about a python+gdb performance issue and a
solution of it.

3. The last one is if you can handle traceframe with python, maybe you
think you can keep analyse the traceframe from target.  But current
tracepoint doesn't it.  You must "tstart", "tstop", parse.
What I handle it is let KGTP supply a special interface in tfile
format.  Then GDB can keep get traceframe from it without stop

> Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]