Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Hui Zhu <teawater@gmail.com>
To: "Marc Brünink" <marc@nus.edu.sg>
Cc: Tom Tromey <tromey@redhat.com>, gdb@sourceware.org
Subject: Re: Tracepoints (and python)
Date: Fri, 21 Dec 2012 08:55:00 -0000	[thread overview]
Message-ID: <CANFwon17zRnhfFWG7t9=z8ZY_4AcpsW+6KeXQkM1=H_tG_fr0w@mail.gmail.com> (raw)
In-Reply-To: <87k3scn69b.fsf@fleche.redhat.com>

On Thu, Dec 20, 2012 at 10:32 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Marc" == Marc Brünink <marc@nus.edu.sg> 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
http://code.google.com/p/kgtp/wiki/hotcode

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
script.

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
tracepoint.

> Tom

Thanks,
Hui


  reply	other threads:[~2012-12-21  8:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-20  2:36 Marc Brünink
2012-12-20 14:33 ` Tom Tromey
2012-12-21  8:55   ` Hui Zhu [this message]
2013-01-02 17:27     ` Tom Tromey
2012-12-28  0:43   ` Doug Evans
2013-01-02 17:28     ` Tom Tromey
2013-01-02 17:44       ` Doug Evans
2013-01-11  7:29         ` Marc Brünink
2013-01-11  8:12           ` Yao Qi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANFwon17zRnhfFWG7t9=z8ZY_4AcpsW+6KeXQkM1=H_tG_fr0w@mail.gmail.com' \
    --to=teawater@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=marc@nus.edu.sg \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox