public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org
Cc: Stan Shebs <stanshebs@earthlink.net>
Subject: Re: Tracepoints and Timestamps
Date: Mon, 07 Nov 2011 17:20:00 -0000	[thread overview]
Message-ID: <201111071720.31400.pedro@codesourcery.com> (raw)
In-Reply-To: <4EB80415.7010304@earthlink.net>

On Monday 07 November 2011 16:15:17, Stan Shebs wrote:
> On 11/7/11 6:53 AM, Abhishek Karoliya wrote:
> > Hi Hui,
> >
> >     Thanks for the pointer ... However after going through the
> > gdbserver source code, I realise that there is no tracepoint support
> > for linux-ppc. So now I have a even bigger problem on my hand.
> >
> > Does anyone know if I can ppc tracepoint support being actively
> > developed and if I can lay my hands on this experimental code.
> >
> 
> The tracepoint support in GDBserver is pretty generic, and if you don't 
> need fast tracepoints, there's not really anything that is arch-specific.
> 
> I would suggest enabling target_supports_tracepoints for ppc and letting 
> us know how it goes.  If it "just works", then we could change the 
> target_supports_tracepoints test to make it unconditional.

We can't.  The backend needs to be able to step over breakpoints
so it can step over tracepoints without gdb involvement.  Which means, it
either needs to support hardware single-step (ppc does), or, it'll need to
know how to software single-step.  No gdbserver port can do the latter.
And it should ideally switch to using gdbserver side breakpoints (z0/Z0
packets, the insert_point/remove_point hooks), so breakpoints and
tracepoints can coexist.

linux-ppc-low.c should install the supports_tracepoints hook like
linux-x86-low.c does:

static int
x86_supports_tracepoints (void)
{
  return 1;
}

and insert_point/remote_point hooks, like x86_insert_point/x86_remove_point.

The Z0 insert/remove code support would ideally be moved to the gdbserver
core side, controlled by a new "use software breakpoints" hook added to
gdbserver's target vector, so that bit of code could be reused.

-- 
Pedro Alves

      reply	other threads:[~2011-11-07 17:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAEEVgBVFNRLqG67VwzF1D63Ro57Sww1HOwyrPBywRPBnHt5Hjg@mail.gmail.com>
2011-11-04 19:06 ` Abhishek Karoliya
2011-11-07  6:41   ` Hui Zhu
2011-11-07 14:53     ` Abhishek Karoliya
2011-11-07 16:15       ` Stan Shebs
2011-11-07 17:20         ` Pedro Alves [this message]

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=201111071720.31400.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb@sourceware.org \
    --cc=stanshebs@earthlink.net \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).