This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
This is a patch to fix the 4 KFAILs (GDB PR/2018) reported in: http://sources.redhat.com/ml/gdb-patches/2005-10/msg00046.html The problem is as follow. We have an array type declared using an enumerated type as the index type: type Index is (One, Two, Three); type ETable is array (Index) of Integer; And then a variable of that type: E_One_Two_Three : ETable := (1, 2, 3); Trying to print the value of this variable in the debugger results in: (gdb) p e_one_two_three $1 = (0 => 1, 2, 3) With array-indexes on, we get: (gdb) set print array-indexes (gdb) p e_one_two_three $2 = (0 => 1, 1 => 2, 2 => 3) The expected output is: (gdb) p e_one_two_three $1 = (1, 2, 3) (gdb) set print array-indexes (gdb) p e_one_two_three $2 = (one => 1, two => 2, three => 3) The debugger should print the indexes using the enumerates ("one", "two" and "three"), not the their underlying values. This is related to the GNAT encoding. The ETable array is defined as follow: .uleb128 0xc # (DIE (0xc1f) DW_TAG_array_type) .long .LASF27 # DW_AT_name: "p__etable" .long 0x3e7 # DW_AT_type .uleb128 0x15 # (DIE (0xc2c) DW_TAG_subrange_type) .long 0x1ab # DW_AT_type [...] So following the array index type, we see a subrange of DIE 0x1ab, defined as: .uleb128 0xe # (DIE (0x1ab) DW_TAG_base_type) .ascii "long int\0" # DW_AT_name The trick is that GDB didn't see that there is a parallel type p__etable___XA, which gives us the real type for the array index. This is document in exp_dbug.ads in gcc/ada: -- Since there is no way for the debugger to obtain the index subtypes -- for an array type, we produce a type that has the name of the -- array type followed by "___XA" and is a record whose field names -- are the names of the types for the bounds. The types of these -- fields is an integer type which is meaningless. And the reason why GDB didn't find this parallel type was because we forgot to store the array type name in our type structure. The attached patch fixes it for array types. I have checked all other "read_*_type" functions in dwarf2read.c, and didn't find any other cases where I think the same will be needed. Either we already store the type name, or I don't see a case where it's needed. So this patch seems enough for now. 2005-10-09 Joel Brobecker <brobecker@adacore.com> * dwarf2read.c (read_array_type): Set the type name if the name attribute is present. Tested on x86-linux, fixes the 4 KFAILs of gdb.ada/arrayidx.exp, no regression. OK to commit? Thanks, -- Joel
Attachment:
dwarf2read.c.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |