From: Joel Brobecker <brobecker@adacore.com>
To: Pedro Alves <palves@redhat.com>, gdb-patches@sourceware.org
Subject: RFC: problems with minimal symbols (without a type)
Date: Thu, 09 Nov 2017 01:25:00 -0000 [thread overview]
Message-ID: <20171109012540.ds5ixw4pq6rclhgc@adacore.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]
Hi Pedro,
You recently made a change to require that minimal symbols be cast
in order to be printed. This is causing some unexpected side-effects
in Ada. The most visible is with exception catchpoints.
Consider any Ada program, trying to insert a catchpoint on a specific
exception now fails:
$ (gdb) catch exception constraint_error
warning: failed to reevaluate internal exception condition for catchpoint 0: 'constraint_error' has unknown type; cast it to its declared type
I suspect people using the version of GNAT produced by distribution
makes such as RedHat probably cannot reproduce the issue, as I understand
the compiler is built with a runtime with full debugging information,
whereas the version AdaCore distributes only provides debugging info
for the few units where we need it.
Another way to show the same issue is to just print constraint_error:
(gdb) p constraint_error
'constraint_error' has unknown type; cast it to its declared type
And unfortunately, the Ada equivalent of casting does not work either:
(gdb) print integer(constraint_error)
'constraint_error' has unknown type; cast it to its declared type
But even if casting were working, should we really also require
a case in a situation like this?
(gdb) p constraint_error'address
$2 = (system.address) 0x62c960 <constraint_error>
Unlike C, 'address returns an object of type system.address,
which is the equivalent of "void *" in C. For minimal symbols
other that integers, the way people typically dump them is by
doing something like that:
(gdb) print {my_type} minsym'address
I looked at the patch series that introduced that change, and
I see where you are coming from, but I am wondering if we should
be doing the same for Ada or not. I think Ada users are a lot
less used to casting (case in point, it took quite a while, even
for myself, to remember what the syntax was), and I fear this is
not going to be well received by the users.
What do you think? Attached is a prototype patch which implements
the original behavior for Ada expressions. It fixes the failures
in exception catchpoints without introducing any regresssion
(x86_64-linux).
Thanks!
--
Joel
[-- Attachment #2: 0001-WIP-Treat-minimal-symbol-as-integers-when-in-Ada.patch --]
[-- Type: text/x-diff, Size: 2033 bytes --]
From acf78c27f8652e2bb2c35fc488766312bccc3487 Mon Sep 17 00:00:00 2001
From: Joel Brobecker <brobecker@adacore.com>
Date: Wed, 8 Nov 2017 19:32:14 -0500
Subject: [PATCH] WIP: Treat minimal symbol as integers when in Ada
---
gdb/ada-lang.c | 15 +++++++++++++++
gdb/eval.c | 2 +-
gdb/value.h | 4 ++++
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c
index 40213b5..8d987a1 100644
--- a/gdb/ada-lang.c
+++ b/gdb/ada-lang.c
@@ -10355,6 +10355,21 @@ ada_evaluate_subexp (struct type *expect_type, struct expression *exp,
return arg1;
+ case OP_VAR_MSYM_VALUE:
+ {
+ (*pos) += 3;
+
+ minimal_symbol *msymbol = exp->elts[pc + 2].msymbol;
+ arg1 = evaluate_var_msym_value (noside, exp->elts[pc + 1].objfile,
+ msymbol);
+ if (noside != EVAL_AVOID_SIDE_EFFECTS
+ && TYPE_CODE (value_type (arg1)) == TYPE_CODE_ERROR)
+ arg1 = ada_value_cast (builtin_type (exp->gdbarch)->builtin_int,
+ arg1, noside);
+
+ return arg1;
+ }
+
case OP_STRING:
{
struct value *result;
diff --git a/gdb/eval.c b/gdb/eval.c
index 94ddfdb..eca4643 100644
--- a/gdb/eval.c
+++ b/gdb/eval.c
@@ -738,7 +738,7 @@ evaluate_var_value (enum noside noside, const block *blk, symbol *var)
/* Helper for evaluating an OP_VAR_MSYM_VALUE. */
-static value *
+value *
evaluate_var_msym_value (enum noside noside,
struct objfile *objfile, minimal_symbol *msymbol)
{
diff --git a/gdb/value.h b/gdb/value.h
index b1b8c6d..64556c5 100644
--- a/gdb/value.h
+++ b/gdb/value.h
@@ -885,6 +885,10 @@ extern char *extract_field_op (struct expression *exp, int *subexp);
extern struct value *evaluate_subexp_with_coercion (struct expression *,
int *, enum noside);
+extern struct value *evaluate_var_msym_value (enum noside noside,
+ struct objfile *objfile,
+ minimal_symbol *msymbol);
+
extern struct value *parse_and_eval (const char *exp);
extern struct value *parse_to_comma_and_eval (const char **expp);
--
2.1.4
next reply other threads:[~2017-11-09 1:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-09 1:25 Joel Brobecker [this message]
2017-11-09 10:47 ` Pedro Alves
2017-11-15 1:35 ` Joel Brobecker
2017-11-15 12:17 ` Pedro Alves
2017-11-15 18:52 ` Joel Brobecker
2017-11-17 0:51 ` Joel Brobecker
2017-11-17 11:32 ` Pedro Alves
2017-11-17 17:19 ` 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=20171109012540.ds5ixw4pq6rclhgc@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@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