From: Phil Muldoon <pmuldoon@redhat.com>
To: tromey@redhat.com
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] PR python/11407
Date: Thu, 24 Jun 2010 22:01:00 -0000 [thread overview]
Message-ID: <4C23D5CB.5040702@redhat.com> (raw)
In-Reply-To: <m3aaqk8foj.fsf@fleche.redhat.com>
On 06/24/2010 07:10 PM, Tom Tromey wrote:
>>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
>
> Phil> This patch is for PR 11407. It also cures the ills in Jan's
> Phil> test-case from last night:
>
> Phil> 2010-06-24 Phil Muldoon <pmuldoon@redhat.com>
> Phil> PR python/11407
> Phil> * printcmd.c (print_variable_and_value): Print error message on
> Phil> caught exception.
>
> This is ok with the changes Jan suggested.
>
> I think the MI commands -stack-list-variables and friends will need
> similar treatment. See mi-cmd-stack.c:list_args_or_locals.
Sorry for missing this, I was running 'info locals' in the MI
interpreter. The MI -stack-list-locals case (as you noted) takes a
different direction from the CLI in printing these cases.
I'm not sure what to do in this case. There seems to be no direct
equivalent of converting an exception to error output on a stream in MI
(or any cases of TRY ... exception handlers). There are many cases of
MI raising an error() though, so I thought it appropriate in our case
to raise a warning() instead. Because of the peculiarities of the MI
cases I just report a warning generically and move on. This is not
totally ideal, but it does allow the error/warning preamble followed
by the actual locals information. IE in my case:
(.. lots and lots of error messages for the Python testcase and ...)
~"RuntimeError: Cannot access memory at address 0x6c756d702f656d57\n"
~"Traceback (most recent call last):\n"
~" File \"/home/pmuldoon/git/stack-list-locals/printers.py\", line 549, in to_string\n"
~" return self.val['_M_dataplus']['_M_p'].lazy_string (length = len)\n"
~"RuntimeError: Cannot access memory at address 0x6c2d6b6361747317\n"
&"warning: <error reading variable>\n"
&"warning: <error reading variable>\n"
^done,locals=[{name="mappedStrings"},{name="tmp"},{name="coll"},{name="str"},{name="stringV"},{name="derivedSet"},{name="stringVV"}]
Which ultimately I think the IDE people want on program
initialization (regardless of errors). At any rate, it is an
improvement over the direct termination at the first error (and no
locals=() data emitted).
WDYT?
Cheers,
Phil
--
diff --git a/gdb/mi/mi-cmd-stack.c b/gdb/mi/mi-cmd-stack.c
index 6797055..fe9fc81 100644
--- a/gdb/mi/mi-cmd-stack.c
+++ b/gdb/mi/mi-cmd-stack.c
@@ -31,7 +31,7 @@
#include "gdb_string.h"
#include "language.h"
#include "valprint.h"
-
+#include "exceptions.h"
enum what_to_list { locals, arguments, all };
@@ -335,27 +335,41 @@ list_args_or_locals (enum what_to_list what, int values, struct frame_info *fi)
&& TYPE_CODE (type) != TYPE_CODE_UNION)
{
struct value_print_options opts;
+ volatile struct gdb_exception except;
+
+ TRY_CATCH (except, RETURN_MASK_ERROR)
+ {
+
+ val = read_var_value (sym2, fi);
+ get_raw_print_options (&opts);
+ opts.deref_ref = 1;
+ common_val_print
+ (val, stb->stream, 0, &opts,
+ language_def (SYMBOL_LANGUAGE (sym2)));
+ }
+ if (except.reason < 0)
+ warning (_("<error reading variable>"));
- val = read_var_value (sym2, fi);
- get_raw_print_options (&opts);
- opts.deref_ref = 1;
- common_val_print
- (val, stb->stream, 0, &opts,
- language_def (SYMBOL_LANGUAGE (sym2)));
ui_out_field_stream (uiout, "value", stb);
}
break;
case PRINT_ALL_VALUES:
{
struct value_print_options opts;
+ volatile struct gdb_exception except;
+
+ TRY_CATCH (except, RETURN_MASK_ERROR)
+ {
+ val = read_var_value (sym2, fi);
+ get_raw_print_options (&opts);
+ opts.deref_ref = 1;
+ common_val_print
+ (val, stb->stream, 0, &opts,
+ language_def (SYMBOL_LANGUAGE (sym2)));
+ }
+ if (except.reason < 0)
+ warning (_("<error reading variable>"));
- val = read_var_value (sym2, fi);
- get_raw_print_options (&opts);
- opts.deref_ref = 1;
- common_val_print
- (val, stb->stream, 0, &opts,
- language_def (SYMBOL_LANGUAGE (sym2)));
- ui_out_field_stream (uiout, "value", stb);
}
break;
}
next prev parent reply other threads:[~2010-06-24 22:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-24 11:33 Phil Muldoon
2010-06-24 15:10 ` Jan Kratochvil
2010-06-24 18:10 ` Tom Tromey
2010-06-24 22:01 ` Phil Muldoon [this message]
2010-06-25 6:56 ` Phil Muldoon
2010-06-25 14:27 ` Phil Muldoon
2010-06-25 18:25 ` Tom Tromey
2010-06-25 21:20 ` Phil Muldoon
2010-07-07 17:02 ` Phil Muldoon
2010-08-09 19:41 ` Phil Muldoon
2010-08-31 18:42 ` Phil Muldoon
2010-09-08 19:25 ` Tom Tromey
2010-06-26 17:10 ` Doug Evans
2010-06-28 6:26 ` André Pönitz
2010-06-28 16:52 ` Tom Tromey
2010-06-29 7:43 ` André Pönitz
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=4C23D5CB.5040702@redhat.com \
--to=pmuldoon@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@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