Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org, vladimir@codesourcery.com
Subject: GDB/MI design question re: Ada exception catchpoints
Date: Wed, 09 Mar 2011 06:27:00 -0000	[thread overview]
Message-ID: <20110309045939.GU30306@adacore.com> (raw)

Hello all,

One of the guys at AdaCore would like to use CDT, and noticed that
some normal CDT notifications do not get triggered when the program
hits an Ada exception catchpoint.  We narrowed down the issue to
the fact that we don't emit the stop reason:

(gdb)
~"\nCatchpoint 2, unhandled CONSTRAINT_ERROR at "
*stopped,frame={addr="0x080497f2",func="test",args=[],file="/[...]/test.adb",fullname="/[...]/test.adb",line="21"},thread-id="1",stopped-threads="all",core="1"
(gdb)

In fact, looking deeper, we get the above, because, well, the
"print_it" routine for Ada exception catchpoints does little more
than `printf ("Catchpoint %d, %s at")', thus not handling the MI case
at all.

But once I rewrote a bit the code to follow what other breakpoint
"print_it" routines do, I now get the following output:

(gdb)
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x0000000000402062",func="foo",args=[],file="foo.adb",fullname="/[...]/foo.adb",line="3"},thread-id="1",stopped-threads="all",core="3"

The front-end no longer has as much information as before.
The fact that we've just hit an exception catchpoint can probably
be deduced from the breakpoint number.  But we are missing the
exception name.

I think that it would be sufficient to add an extra field providing
that exception name:

*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",exception-name="CONSTRAINT_ERROR",frame={addr="0x0000000000402062",func="foo",args=[],file="foo.adb",fullname="/[...]/foo.adb",line="3"},thread-id="1",stopped-threads="all",core="3"

If the field is missing, it means that we were unable to determine
that exception name (in the CLI, we print "exception" instead of
"CONSTRAINT_ERROR").

Would that be OK? I don't want to change the current code until
we address this issue, because CDT apparently works around the
current situation by parsing the contents of the console stream
output (the `~"..."' stuff).

-- 
Joel


             reply	other threads:[~2011-03-09  5:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-09  6:27 Joel Brobecker [this message]
2011-03-10 10:12 ` Vladimir Prus
2011-03-10 11:51   ` 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=20110309045939.GU30306@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=vladimir@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