Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC/RFA] Add support for catch Ada exceptions
Date: Sun, 31 Dec 2006 21:37:00 -0000	[thread overview]
Message-ID: <20061231213707.GA26604@nevyn.them.org> (raw)
In-Reply-To: <20061230032111.GB27642@adacore.com>

This is quite elegant really.

On Sat, Dec 30, 2006 at 07:21:11AM +0400, Joel Brobecker wrote:
> Hello,
> 
> Here is a patch that adds support for "catch"-ing Ada exceptions.
> There are 3 different kinds of commands I am introducing:
> 
>   - catch exception [exception name]
>     If the exception name is omitted, then all Ada exception are caught.
> 
>   - catch exception unhandled
>     This catchpoint will stop if the program raises an exception
>     that is not handled (and eventually causes the task or program death)
> 
>   - catch exception assert
>     This catchpoint stops the program when assertions in the program
>     fail. With GNAT, they are inserted like this:
> 
>         [code]
>         pragma Assert (boolean_EXPRESSION);
>         [code]
> 
>     They are activated only if the unit was compiled with assertions
>     enabled.

This sounds an awful lot like "catch throw" and "catch catch" for C++.
I realize you'll want different terms, but should we make them share
a common mechanism?

Also, is this more like "catch catch" or "catch throw"?  I think it's
more like "catch throw" from your example, i.e. stops you at the
raise site.  If so, the other alternative may be useful too (if there's
any way to implement that in Ada).  If not, that's not a big deal.
Depends on your exceptions implementation.

If possible, I'd like to have the same command work for both C++ and
Ada in a mixed binary.  I don't think it's possible to throw exceptions
between them yet, but I'm sure it's been talked about.

On the other hand, if this makes things too complex, we can postpone
it.

> In terms of implementation, these catchpoints are implemented using
> breakpoints inside known functions of the GNAT runtime. However,
> when we stop at these breakpoints, it would be confusing to the user
> to leave them there. This is why, after the catchpoint hit, we go up
> the stack automatically, and find the first "printable" frame, that
> is a frame that is not part of the GNAT runtime and that has debugging
> info (see ada_find_printable_frame).

Nice.  I meant to do this for the C++ equivalent, too, but never got
around to it.

As for the breakpoints, could you please check if you really need
new bp_* constants?  It's hard to spot in the history of breakpoint.c,
but when I implemented something similar for C++, I added a "virtual
table" that let us mark the breakpoint as a normal bp_breakpoint,
and that simplified the change a bit.  Search for
handle_gnu_v3_exceptions.  You're already using the virtual table,
I see.  I couldn't tell from the breakpoint.c changes quite why
you needed new bp constants.  I guess avoiding printing
the condition might be one reason?

The existing cases for "bp_catch_catch" and "bp_catch_throw" date
back to HP/UX, which used a rather different OS mechanism to intercept
exceptions, I believe.  Treating them as normal breakpoints scales
better and I think it will simplify the patch.

Suppressing the "breakpoint also set at" for things with a custom
set of breakpoint ops might be good for the C++ version too, just like
your FIXME.

-- 
Daniel Jacobowitz
CodeSourcery


  parent reply	other threads:[~2006-12-31 21:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-30  3:20 Joel Brobecker
2006-12-30 15:55 ` Eli Zaretskii
2006-12-31  4:39   ` Joel Brobecker
2006-12-31 21:37 ` Daniel Jacobowitz [this message]
2007-01-01  4:42   ` Joel Brobecker
2007-01-01 16:19     ` Daniel Jacobowitz
2007-01-02  6:06       ` [RFA] Add support for catch Ada exceptions (take 2) Joel Brobecker
2007-01-02  6:15         ` Joel Brobecker
2007-01-03  2:47           ` Daniel Jacobowitz
2007-01-04  5:32             ` Joel Brobecker

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=20061231213707.GA26604@nevyn.them.org \
    --to=drow@false.org \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /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