This is the mail archive of the
gdb-cvs@sourceware.org
mailing list for the GDB project.
gdb and binutils branch master updated. 8a48ac9579f34efea9bc4f2d5b02230e2ac3dfc1
- From: brobecke at sourceware dot org
- To: gdb-cvs at sourceware dot org
- Date: 13 Dec 2013 08:56:36 -0000
- Subject: gdb and binutils branch master updated. 8a48ac9579f34efea9bc4f2d5b02230e2ac3dfc1
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".
The branch, master has been updated
via 8a48ac9579f34efea9bc4f2d5b02230e2ac3dfc1 (commit)
from fb5e3d5c693cf9d56188a0ebd7ead5eba99bfdb4 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8a48ac9579f34efea9bc4f2d5b02230e2ac3dfc1
commit 8a48ac9579f34efea9bc4f2d5b02230e2ac3dfc1
Author: Joel Brobecker <brobecker@adacore.com>
Date: Wed Nov 27 17:42:24 2013 +0400
wrong dimension found in ada-lang.c:ada_array_bound_from_type
This function has the following code:
elt_type = type;
for (i = n; i > 1; i--)
elt_type = TYPE_TARGET_TYPE (type);
For multi-dimension arrays, the code above tries to find the array
type corresponding to the dimension we're trying to inspect.
The problem is that, past the second dimension, the loop does
nothing other than repeat the first iteration. There is a little
thinko where it got the TYPE_TARGET_TYPE of TYPE instead of ELT_TYPE!
To my surprise, I was unable to produce an Ada exemple that demonstrated
the problem. That's because the examples I created all trigger a parallel
___XA type which we then use in place of the ELT_TYPE in order to
determine the bounds - see the code that immediately follows our
loop above:
index_type_desc = ada_find_parallel_type (type, "___XA");
ada_fixup_array_indexes_type (index_type_desc);
if (index_type_desc != NULL)
[...]
So, in order to avoid depending on an Ada example where the compiler
can potentially decide one way or the other, I decided to use an
artificial example, written in C. With ...
int multi[1][2][3];
... forcing the language to Ada, and trying to print the 'last,
we get:
(gdb) p multi'last(1)
$1 = 0
(gdb) p multi'last(2)
$2 = 1
(gdb) p multi'last(3)
$3 = 1 <<<--- This should be 2!
Additionally, I noticed that a couple of check_typedef's were missing.
This patch adds them. And since the variable in question only gets
used within an "else" block, I moved the variable declaration and
use inside that block - making it clear what the scope of the variable
is.
gdb/ChangeLog:
* ada-lang.c (ada_array_bound_from_type): Move the declaration
and assignment of variable "elt_type" inside the else block
where it is used. Add two missing check_typedef calls.
Fix bug where we got TYPE's TYPE_TARGET_TYPE, where in fact
we really wanted to get ELT_TYPE's TYPE_TARGET_TYPE.
gdb/testsuite/ChangeLog:
* gdb.ada/arraydim: New testcase.
-----------------------------------------------------------------------
Summary of changes:
gdb/ChangeLog | 8 ++++
gdb/ada-lang.c | 15 ++++---
gdb/testsuite/ChangeLog | 4 ++
gdb/testsuite/gdb.ada/arraydim.exp | 70 ++++++++++++++++++++++++++++++++
gdb/testsuite/gdb.ada/arraydim/foo.adb | 30 ++++++++++++++
gdb/testsuite/gdb.ada/arraydim/inc.c | 18 ++++++++
gdb/testsuite/gdb.ada/arraydim/pck.adb | 22 ++++++++++
gdb/testsuite/gdb.ada/arraydim/pck.ads | 20 +++++++++
8 files changed, 181 insertions(+), 6 deletions(-)
create mode 100644 gdb/testsuite/gdb.ada/arraydim.exp
create mode 100644 gdb/testsuite/gdb.ada/arraydim/foo.adb
create mode 100644 gdb/testsuite/gdb.ada/arraydim/inc.c
create mode 100644 gdb/testsuite/gdb.ada/arraydim/pck.adb
create mode 100644 gdb/testsuite/gdb.ada/arraydim/pck.ads
hooks/post-receive
--
gdb and binutils