From: Joel Brobecker <brobecker@adacore.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: should be fixed: Regression for gdb.ada/arrayidx.exp [Re: pushed: [commit/Ada] Ignore __XA types when redundant.]
Date: Thu, 20 Nov 2014 09:47:00 -0000 [thread overview]
Message-ID: <20141120094656.GS5774@adacore.com> (raw)
In-Reply-To: <20141120064518.GA29026@host2.jankratochvil.net>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
> > > With gcc-gnat-4.9.2-1.fc21.x86_64 I see
> > > -PASS: gdb.ada/arrayidx.exp: print r_two_three, indexes off
> > > +FAIL: gdb.ada/arrayidx.exp: print r_two_three, indexes off
> > > -PASS: gdb.ada/arrayidx.exp: print r_two_three
> > > +FAIL: gdb.ada/arrayidx.exp: print r_two_three
[...]
> http://people.redhat.com/jkratoch/arrayidx.tar.xz
Thanks. This allowed me to understand the source of the problem,
and to push a fix (attached).
gdb/ChangeLog:
* ada-lang.c (ada_is_redundant_range_encoding): Return 0
if the TYPE_CODE of range_type's base type does not match
the TYPE_CODE of encoding_type's base type.
Tested on x86_64-linux.
--
Joel
[-- Attachment #2: 0001-Ada-XA-type-is-not-redundant-if-the-ranges-subtypes-.patch --]
[-- Type: text/x-diff, Size: 4538 bytes --]
From 005e2509a167c05719df3a3edd966865110a5052 Mon Sep 17 00:00:00 2001
From: Joel Brobecker <brobecker@adacore.com>
Date: Thu, 20 Nov 2014 12:10:41 +0400
Subject: [PATCH] [Ada] XA type is not redundant if the ranges' subtypes do not
match
Jan noticed that gdb.ada/arrayidx.exp regressed after I applied
the following patch:
commit 8908fca5772fcff9f7766158ba2aa59f5a2b1f68
Author: Joel Brobecker <brobecker@adacore.com>
Date: Sat Sep 27 09:09:34 2014 -0700
Subject: [Ada] Ignore __XA types when redundant.
What happens is that we're trying to print the value of
r_two_three, which is defined as follow:
type Index is (One, Two, Three);
type RTable is array (Index range Two .. Three) of Integer;
R_Two_Three : RTable := (2, 3);
The expected output is:
(gdb) p r_two_three
$1 = (two => 2, 3)
But after the patch above was applied, with the program program
compiled using gcc-gnat-4.9.2-1.fc21.x86_64 (x86_64-linux),
the output becomes:
(gdb) p r_two_three
$1 = (2, 3)
(the name of the first bound is missing). The problem comes from
the fact that the compiler described the array's index type as
a plain base type, instead of as a subrange of the enumerated type.
More particularly, this is what gcc-gnat-4.9.2-1.fc21.x86_64
generated:
<3><7ce>: Abbrev Number: 9 (DW_TAG_array_type)
<7cf> DW_AT_name : (indirect string, offset: 0xc13): p__rtable
[...]
<7d7> DW_AT_GNAT_descriptive_type: <0x98a>
[...]
<4><7df>: Abbrev Number: 8 (DW_TAG_subrange_type)
<7e0> DW_AT_type : <0xa79>
where DIE 0xa79 is:
<1><a79>: Abbrev Number: 2 (DW_TAG_base_type)
<a7a> DW_AT_byte_size : 8
<a7b> DW_AT_encoding : 7 (unsigned)
<a7c> DW_AT_name : (indirect string, offset: 0xfc): sizetype
The actual array subrange type can be found in the array's
parallel XA type (the DW_AT_GNAT_descriptive_type).
The recent commit correctly found that that bounds taken from
the descriptive type are the same as bounds of our array's index
type. But it failed to notice that ignoring this descriptive
type would make us lose the actual array index type, making us
think that we're printing an array indexed by integers.
I hadn't seen that problem, because the compiler I used produced
debugging info where the array's index type is correctly described:
<3><79f>: Abbrev Number: 10 (DW_TAG_array_type)
<7a0> DW_AT_name : (indirect string, offset: 0xb3d): p__rtable
[...]
<4><7b0>: Abbrev Number: 8 (DW_TAG_subrange_type)
<7b1> DW_AT_type : <0x9b2>
<7b5> DW_AT_upper_bound : 2
... where DIE 0x9b2 leads us to ...
<3><9b2>: Abbrev Number: 9 (DW_TAG_subrange_type)
[...]
<9b8> DW_AT_type : <0x962>
<2><962>: Abbrev Number: 22 (DW_TAG_enumeration_type)
<963> DW_AT_name : (indirect string, offset: 0xb34): p__index
[...]
This patch fixes the issue by also making sure that the subtype
of the original range type does match the subtype found in the
descriptive type.
gdb/ChangeLog:
* ada-lang.c (ada_is_redundant_range_encoding): Return 0
if the TYPE_CODE of range_type's base type does not match
the TYPE_CODE of encoding_type's base type.
---
gdb/ChangeLog | 6 ++++++
gdb/ada-lang.c | 11 +++++++++++
2 files changed, 17 insertions(+)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 5f58e6c..75b739e 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+2014-11-20 Joel Brobecker <brobecker@adacore.com>
+
+ * ada-lang.c (ada_is_redundant_range_encoding): Return 0
+ if the TYPE_CODE of range_type's base type does not match
+ the TYPE_CODE of encoding_type's base type.
+
2014-11-19 Joel Brobecker <brobecker@adacore.com>
* ada-lang.c (ada_unqualified_name): Return DECODED_NAME if
diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c
index e46ad8e..122aaf4 100644
--- a/gdb/ada-lang.c
+++ b/gdb/ada-lang.c
@@ -8334,6 +8334,17 @@ ada_is_redundant_range_encoding (struct type *range_type,
gdb_assert (TYPE_CODE (range_type) == TYPE_CODE_RANGE);
+ if (TYPE_CODE (get_base_type (range_type))
+ != TYPE_CODE (get_base_type (encoding_type)))
+ {
+ /* The compiler probably used a simple base type to describe
+ the range type instead of the range's actual base type,
+ expecting us to get the real base type from the encoding
+ anyway. In this situation, the encoding cannot be ignored
+ as redundant. */
+ return 0;
+ }
+
if (is_dynamic_type (range_type))
return 0;
--
1.9.1
next prev parent reply other threads:[~2014-11-20 9:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-14 16:44 [commit/Ada] Ignore __XA types when redundant Joel Brobecker
2014-11-19 8:48 ` pushed: " Joel Brobecker
2014-11-19 18:19 ` Regression for gdb.ada/arrayidx.exp [Re: pushed: [commit/Ada] Ignore __XA types when redundant.] Jan Kratochvil
2014-11-20 4:10 ` Joel Brobecker
2014-11-20 6:45 ` Jan Kratochvil
2014-11-20 9:47 ` Joel Brobecker [this message]
2014-11-20 9:57 ` should be fixed: " Jan Kratochvil
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=20141120094656.GS5774@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@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