Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Stan Shebs <stan@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Make tracepoints into breakpoints
Date: Mon, 30 Mar 2009 16:56:00 -0000	[thread overview]
Message-ID: <20090330161015.GA18050@adacore.com> (raw)
In-Reply-To: <20090330153348.GY9472@adacore.com>

> I'd also like to look at your patch again sometime soon, to figure out
> whether it'd make sense or not for tracepoints to have their own
> breakpoint_ops routines... To be continued :)

I was too impatient, so I looked at it again ;).

Regarding the use of the breakpoint_ops routine, it makes sense for
some of them, but not all. For instance, the print_one "method"
could be kept as NULL. For the print_mention method, it would make
sense to have a dedicated method, but that method currently does not
handle the "say_where" flag.

So I'm 50/50 on this topic. I would probably have used the breakpoint_ops
myself, because I have this idealistic goal of converting everything to
using breakpoint ops one day. The downside for tracepoints is that
the implementation style gets fragmented between the "old" style and
the "new" one. The upside is that using breakpoint_ops now puts us
closer to that idealistic goal. It's still not clear to me that this
goal is attainable at all, which is why I'm not too attached to using
breakpoint_ops in your case.

I propose you let me ramble about it on my own, and do nothing (unless
you feel like it) :-).

-- 
Joel


  reply	other threads:[~2009-03-30 16:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-27 19:57 Stan Shebs
2009-03-28  9:07 ` Eli Zaretskii
2009-03-30 16:10   ` Stan Shebs
2009-03-28 18:11 ` Eli Zaretskii
2009-03-30 15:44 ` Joel Brobecker
2009-03-30 16:56   ` Joel Brobecker [this message]
2009-03-30 18:29   ` Stan Shebs
2009-03-30 22:21     ` Joel Brobecker
2009-03-30 23:01       ` Stan Shebs
2009-03-30 22:07   ` Stan Shebs

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=20090330161015.GA18050@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=stan@codesourcery.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