Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Aleksandar Ristovski <aristovski@qnx.com>
Cc: Joel Brobecker <brobecker@adacore.com>, gdb@sources.redhat.com
Subject: Re: catchpoint - bptype
Date: Mon, 28 Apr 2008 21:08:00 -0000	[thread overview]
Message-ID: <20080428173754.GA4955@caradoc.them.org> (raw)
In-Reply-To: <48160959.2050404@qnx.com>

On Mon, Apr 28, 2008 at 01:28:57PM -0400, Aleksandar Ristovski wrote:
> I agree, but without knowing the long term intent it is hard to
> tell. At the moment it introduces slight complication since only
> "catch" and "throw" use ops and nothing else (and, therefore, take
> different printing route than anything else). I can see how
> breakpoint_ops can be very useful, if used consistently - it could
> be used to, for example, get rid of the switch statements you
> mentioned above.

Why do you assume there is a long term intent? :-)

I don't want to add new elements to those switches unless they are
really for things that do not behave like breakpoints.  I'd be happy
to see patches removing existing cases.  That's why, when I wrote new
code to catch C++ exceptions, I used breakpoint_ops.

> (gdb) info b
> Num     Type           Disp Enb Address    What
> 2       breakpoint     keep y   0xb7f75896 exception catch
> 3       catch fork     keep y
> (gdb)
>
> See how "fork" is cool and "catch" isn't. "Catch" looks just like
> any other breakpoint; the only diff. is in "What" field, while catch
> fork is clearly a catchpoint.

If you can convince us it matters, we can change the output.
Personally I think "breakpoint on exception catch" is a perfectly
reasonable thing to call it - that's what it is.  The fork catchpoints
are not like a breakpoint, though, since they do not correspond to
any code address - just an OS event.

-- 
Daniel Jacobowitz
CodeSourcery


  parent reply	other threads:[~2008-04-28 17:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-28 18:13 Aleksandar Ristovski
2008-04-28 18:22 ` Joel Brobecker
2008-04-28 20:51   ` Aleksandar Ristovski
2008-04-28 20:09     ` Aleksandar Ristovski
2008-04-28 21:08     ` Daniel Jacobowitz [this message]
2008-04-29 17:05       ` Aleksandar Ristovski
2008-04-29 17:49         ` Daniel Jacobowitz

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=20080428173754.GA4955@caradoc.them.org \
    --to=drow@false.org \
    --cc=aristovski@qnx.com \
    --cc=brobecker@adacore.com \
    --cc=gdb@sources.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