From: Daniel Jacobowitz <drow@mvista.com>
To: Joel Brobecker <brobecker@gnat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] Unexpected automatic language switch - get_frame_language()
Date: Wed, 10 Dec 2003 19:18:00 -0000 [thread overview]
Message-ID: <20031210191848.GA22438@nevyn.them.org> (raw)
In-Reply-To: <20031210191614.GK1296@gnat.com>
On Wed, Dec 10, 2003 at 02:16:14PM -0500, Joel Brobecker wrote:
> [quick reply before I run to catch my flight]
> > You may want to look in the archives for the breakpoint_ops and catch
> > exception patches I posted earlier this year; they're broader but do
> > essentially the same thing.
>
> Wildo.
>
> > Personally I don't like this "language dependent breakpoint syntax"
> > idea. Here's one reason why: judging from your implementation I bet
> > that a breakpoint on the starting instruction of the exception raising
> > function will cause this magic to happen.
>
> I don't think so, because we actually also added a field in the
> breakpoint structure that says whether the breakpoint is an exception
> breakpoint or not. So what happens is that we only try to walk up the
> stack only if that flag is set.
>
> I should have mentionned that in my previous message, my bad.
>
> Incidentally, this makes our change a bit more intrusive than it
> actually looks from my previous message. Given yours and Andrew's
> feedback, I am sold on the "catch" approach, but I need to discuss this
> within ACT. We do have a backward compatibilty problem, since this
> command has been used for a long time by our users, now... In any case,
> this is orthogonal to how this will be supported by the FSF version
> of GDB, so it's not something for you to worry about, our problem.
It also makes the issue very easy for you to handle at ACT. Just
add the first hook in the same place and translate "break exception" to
"catch raise" and you should be fine. Switching the internal
implementation to make catch raise work should not be all that
difficult.
> > With "catch exception" that information is stored at a higher level,
> > so you can break *0x08010102 and _not_ have GDB try to walk up a
> > couple of frames.
>
> Same for Ada exception breakpoints.
OK, that makes me feel much better about it :)
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2003-12-10 19:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-05 22:48 Joel Brobecker
2003-12-05 23:57 ` Michael Snyder
2003-12-06 0:18 ` Joel Brobecker
2003-12-06 0:28 ` Andrew Cagney
2003-12-10 1:50 ` Joel Brobecker
2003-12-10 16:14 ` Andrew Cagney
2003-12-10 17:42 ` Joel Brobecker
2003-12-06 0:42 ` Michael Snyder
2003-12-10 17:47 ` Daniel Jacobowitz
2003-12-10 18:10 ` Joel Brobecker
2003-12-10 18:20 ` Daniel Jacobowitz
2003-12-10 19:16 ` Joel Brobecker
2003-12-10 19:18 ` Daniel Jacobowitz [this message]
2003-12-10 18:33 ` Ada's throw/catch; Was: " Andrew Cagney
2003-12-10 19:04 ` 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=20031210191848.GA22438@nevyn.them.org \
--to=drow@mvista.com \
--cc=brobecker@gnat.com \
--cc=gdb-patches@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