Re: [RFC] DW_AT_type missing from DW_TAG_subrange_type

[Denis PILAT <denis.pilat@st.com>]

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.  */