aboutsummaryrefslogtreecommitdiff
path: root/depcomp
diff options
context:
space:
mode:
authorJoel Brobecker <brobecker@adacore.com>2015-03-31 07:59:35 -0700
committerJoel Brobecker <brobecker@adacore.com>2015-05-05 10:42:07 -0700
commit75ea58593b839653b6d2bc69571a8a73e8adebe4 (patch)
tree5fe8e0ef6104f9af113b0f5e046baeab4c97c6bb /depcomp
parentc7ad08e6e5ff0768f5f0aeed12864a7bab588386 (diff)
downloadgdb-75ea58593b839653b6d2bc69571a8a73e8adebe4.zip
gdb-75ea58593b839653b6d2bc69571a8a73e8adebe4.tar.gz
gdb-75ea58593b839653b6d2bc69571a8a73e8adebe4.tar.bz2
preserve the bit stride when resolving an array type.
Consider the following (Ada) variable... A1 : Array_Type := (1 => (I => 0, S => <>), 2 => (I => 1, S => "A"), 3 => (I => 2, S => "AB")); ... where Array_Type is an array of records whose size is variable: subtype Small_Type is Integer range 0 .. 10; type Record_Type (I : Small_Type := 0) is record S : String (1 .. I); end record; type Array_Type is array (Integer range <>) of Record_Type; Trying to print the value of this array currently results in the following error: (gdb) p a1 Cannot access memory at address 0x61c000 What happens in this case, is that the compiler describes our array as an array with a specific stride (and bounds being static 1..3): <1><749>: Abbrev Number: 10 (DW_TAG_array_type) <74a> DW_AT_name : (indirect string, offset: 0xb6d): pck__T18s <74e> DW_AT_byte_stride : 16 <74f> DW_AT_type : <0x6ea> <2><757>: Abbrev Number: 11 (DW_TAG_subrange_type) <758> DW_AT_type : <0x75e> <75c> DW_AT_upper_bound : 3 This is because we cannot use, in this case, the size of the record to determine that stride, since the size of the record depends on its contents. So the compiler helps us by providing that stride. The problems start when trying to resolve that type. Because the elements contained in that array type are dynamic, the array itself is considered dynamic, and thus we end up creating a resolved version of that array. And during that resolution, we were not handling the case where the array had a stride. See gdbtypes.c::resolve_dynamic_array... return create_array_type (copy_type (type), elt_type, range_type); As a result, we created an array whose stride was based on the size of elt_type, which a record whose size isn't static and irrelevant regardless. This patch fixes is by calling create_array_type_with_stride instead. As it happens, there is another issue for us to be able to print the value of our array, but those are independent of this patch and will be handled separately. For now, the patch allows us to get rid of the first error, and the output is now: (gdb) p a1 $1 = ( gdb/ChangeLog: * gdbtypes.c (resolve_dynamic_array): Use create_array_type_with_stride instead of create_array_type.
Diffstat (limited to 'depcomp')
0 files changed, 0 insertions, 0 deletions