This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] DW_AT_type missing from DW_TAG_subrange_type
Daniel Jacobowitz wrote:
On Tue, Apr 03, 2007 at 03:23:56PM +0200, Denis PILAT wrote:
For the global variable declared like that
int array[] = {1, 2, 3, 4};
the dwarf information generated by our specific compiler is missing DW_AT_type
missing from DW_TAG_subrange_type.
Usually in dwarf2 information (ie like the bellow example for gcc4 under
linux), the DW_AT_type exists for subranges :
< 175 (0xaf) > DW_TAG_array_type
| DW_AT_sibling : < 191 (0xbf) >
| DW_AT_type : < 168 (0xa8) >
`--------------------------
< 184 (0xb8) > DW_TAG_subrange_type
* | DW_AT_type : < 191 (0xbf) >* <<<<<-------- missing from my elf
file
| DW_AT_upper_bound : DW_AT_upper_bound(DW_FORM_data1) : 3
`--------------------------
Conveniently, the DWARF 3 standard specifies what this means (DWARF 2
may also; I didn't check). From the standard:
If the subrange entry has no type attribute describing the basis type,
the basis type is assumed to be the same as the object described by
the lower bound attribute (if it references an object). If there is no
lower bound attribute, or that attribute does not reference an object,
the basis type is the type of the upper bound or count attribute (if
either of them references an object). If there is no upper bound or
count attribute, or neither references an object, the type is assumed
to be the same type, in the source language of the compilation unit
containing the subrange entry, as a signed integer with the same size
as an address on the target machine.
Since we do not handle objects for bounds yet, we're only interested
in that last case. So, we should use an integer type the size of an
address. Try using dwarf_base_type (DW_ATE_signed, TARGET_ADDR_BIT /
8, cu)?
Tried, it works as well.
That function is, in fact, very buggy. We should fix it. It has
hardcoded sizes of 1, 2, 4 for char, short, int and doesn't support
long long at all.
And you want me to use it, thanks for the gift !-)
I'm also wondering about the code:
base_type = die_type (die, cu);
if (base_type == NULL)
{
complaint (&symfile_complaints,
_("DW_AT_type missing from DW_TAG_subrange_type"));
return;
}
It seems we'll never have (base_type == NULL). Am I right ?
May be it's time to remove that as well. The complaints seems to be in a better
place in my patch.
You're right; please do.
Done
Here is the proposed patch. No regression in the testsuite for native
linux target.
Ok for commit ?
--
Denis
2007-04-18 Denis Pilat <denis.pilat@st.com>
* dwarf2read.c (read_subrange_type): Use of DW_ATE_signed default type
when missing from DW_TAG_subrange_type. Remove the handling of null
return from die_type().
Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.217
diff -u -p -r1.217 dwarf2read.c
--- dwarf2read.c 11 Apr 2007 16:04:22 -0000 1.217
+++ dwarf2read.c 18 Apr 2007 12:42:20 -0000
@@ -4914,16 +4914,13 @@ read_subrange_type (struct die_info *die
return;
base_type = die_type (die, cu);
- if (base_type == NULL)
+ if (TYPE_CODE (base_type) == TYPE_CODE_VOID)
{
complaint (&symfile_complaints,
_("DW_AT_type missing from DW_TAG_subrange_type"));
- return;
+ base_type = dwarf_base_type (DW_ATE_signed, TARGET_ADDR_BIT /8, cu);
}
- if (TYPE_CODE (base_type) == TYPE_CODE_VOID)
- base_type = alloc_type (NULL);
-
if (cu->language == language_fortran)
{
/* FORTRAN implies a lower bound of 1, if not given. */