aboutsummaryrefslogtreecommitdiff
path: root/gdb/ada-varobj.c
diff options
context:
space:
mode:
authorJoel Brobecker <brobecker@adacore.com>2015-01-14 18:39:24 +0400
committerJoel Brobecker <brobecker@adacore.com>2015-01-29 12:07:25 +0400
commit4a0ca9ec1ee3bc18da72ce42cdd7c2959e58aa76 (patch)
tree5b9c04b33d2577a06d6fe79fa90d029ae8a82076 /gdb/ada-varobj.c
parentddb87a81ac5b031da67fb251b2c11a94e9834ae3 (diff)
downloadfsf-binutils-gdb-4a0ca9ec1ee3bc18da72ce42cdd7c2959e58aa76.zip
fsf-binutils-gdb-4a0ca9ec1ee3bc18da72ce42cdd7c2959e58aa76.tar.gz
fsf-binutils-gdb-4a0ca9ec1ee3bc18da72ce42cdd7c2959e58aa76.tar.bz2
[Ada/varobj] number of children of null pointer to dynamic array.
This is preparation work to avoid a regression in the Ada/varobj. An upcoming patch is going to add support for types in DWARF which have dynamic properties whose value is a reference to another DIE. Consider for instance the following declaration: type Variant_Type (N : Int := 0) is record F : String(1 .. N) := (others => 'x'); end record; type Variant_Type_Access is access all Variant_Type; VTA : Variant_Type_Access := null; This declares a variable "VTA" which is an access (=pointer) to a variant record Variant_Type. This record contains two components, the first being "N" (the discriminant), and the second being "F", an array whose lower bound is 1, and whose upper bound depends on the value of "N" (the discriminant). Of interest to us, here, is that second component ("F"), and in particular its bounds. The debugging info, and in particular the info for the array looks like the following... .uleb128 0x9 # (DIE (0x91) DW_TAG_array_type) .long .LASF16 # DW_AT_name: "bar__variant_type__T2b" .long 0xac # DW_AT_GNAT_descriptive_type .long 0x2cb # DW_AT_type .long 0xac # DW_AT_sibling .uleb128 0xa # (DIE (0xa2) DW_TAG_subrange_type) .long 0xc4 # DW_AT_type .long 0x87 # DW_AT_upper_bound .byte 0 # end of children of DIE 0x91 ... where the upper bound of the array's subrange type is a reference to "n"'s DIE (0x87): .uleb128 0x8 # (DIE (0x87) DW_TAG_member) .ascii "n\0" # DW_AT_name [...] Once the patch to handle this dynamic property gets applied, this is what happens when creating a varobj for variable "VTA" (whose value is null), and then trying to list its children: (gdb) -var-create vta * vta ^done,name="vta",numchild="2",value="0x0", type="bar.variant_type_access",has_more="0" (gdb) -var-list-children 1 vta ^done,numchild="2", children=[child={name="vta.n",[...]}, child={name="vta.f",exp="f", numchild="43877616", <<<<----- value="[43877616]", <<<<----- type="array (1 .. n) of character"}], has_more="0" It has an odd number of children. In this case, we cannot really determine the number of children, since that number depends on the value of a field in a record for which we do not have a value. Up to now, the value we've been displaying is zero - meaning we have an empty array. What happens in this case, is that, because the VTA is a null pointer, we're not able to resolve the pointer's target type, and therefore end up asking ada_varobj_get_array_number_of_children to return the number of elements in that array; for that, it relies blindly on get_array_bounds, which assumes the type is no longer dynamic, and therefore the reads the bound without seeing that it's value is actually a reference rather than a resolved constant. This patch prevents the issue by explicitly handling the case of dynamic arrays, and returning zero child in that case. gdb/ChangeLog: * ada-varobj.c (ada_varobj_get_array_number_of_children): Return zero if PARENT_VALUE is NULL and parent_type's range type is dynamic. gdb/testsuite/ChangeLog: * gdb.ada/mi_var_array: New testcase. Tested on x86_64-linux.
Diffstat (limited to 'gdb/ada-varobj.c')
-rw-r--r--gdb/ada-varobj.c12
1 files changed, 12 insertions, 0 deletions
diff --git a/gdb/ada-varobj.c b/gdb/ada-varobj.c
index 25b1a38..690ee49 100644
--- a/gdb/ada-varobj.c
+++ b/gdb/ada-varobj.c
@@ -240,6 +240,18 @@ ada_varobj_get_array_number_of_children (struct value *parent_value,
{
LONGEST lo, hi;
+ if (parent_value == NULL
+ && is_dynamic_type (TYPE_INDEX_TYPE (parent_type)))
+ {
+ /* This happens when listing the children of an object
+ which does not exist in memory (Eg: when requesting
+ the children of a null pointer, which is allowed by
+ varobj). The array index type being dynamic, we cannot
+ determine how many elements this array has. Just assume
+ it has none. */
+ return 0;
+ }
+
if (!get_array_bounds (parent_type, &lo, &hi))
{
/* Could not get the array bounds. Pretend this is an empty array. */