Re: DW_TAG_imported_declaration DW_TAG_base_type w/o DW_AT_name[Re: using directive patch]

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 16 Jun 2009 17:12:39 +0200, Sami Wagiaalla wrote:
> Jan Kratochvil wrote:
>> On Sun, 07 Sep 2008 20:36:12 +0200, Jan Kratochvil wrote:
>>> +/* Read the import statement specified by the given die and record 
>>> it.  */ +
>>> +static void
>>> +read_import_statement (struct die_info *die, struct dwarf2_cu *cu)
>>> +{
>> ...
>>> +  import_attr = dwarf2_attr (die, DW_AT_import, cu);
>> ...
>>> +  imported_die = follow_die_ref (die, import_attr, &cu);
>>> +  imported_name = dwarf2_name (imported_die, cu);

The important difference here is "imported_die".  It is not "die" here.

>>> +  if (imported_name == NULL)
>>> +    {
>>> +      /* C++ imports from std:: DW_TAG_base_type with no DW_AT_name - why?  */
>>> +      return;
>>> +    }
>
>> (2) DW_TAG_imported_declaration -> DW_TAG_base_type with no DW_AT_name:
>>
>>  <1><46>: Abbrev Number: 4 (DW_TAG_namespace)
>>     <47>   DW_AT_name        : std
>>  <2><51>: Abbrev Number: 5 (DW_TAG_imported_declaration)
>>     <54>   DW_AT_import      : <0x50e>  [Abbrev Number: 24 (DW_TAG_base_type)]
>>  <1><50e>: Abbrev Number: 24 (DW_TAG_base_type)
>>     <50f>   DW_AT_byte_size   : 8
>>     <510>   DW_AT_encoding    : 5       (signed)
>>
>>     I do not see a meaning of such import - if it has no name.  But this bug
>>     may be already covered by PR debug/14168 or possibly by PR debug/14169.
>>
>
> Is this a bug though. This imports the type specified by 0x50e keeping its
> name in the current context.
>
> like here:
>
> namespace A{
>   class B{
>   public:
>     int	x;
>   };
> }
>
> int main(){
>   using A::B;
>   B b;
>   return 0;
> }
>
> ...
>  <2><7b>: Abbrev Number: 8 (DW_TAG_imported_declaration)
>     <7c>   DW_AT_decl_file   : 1
>     <7d>   DW_AT_decl_line   : 9
>     <7e>   DW_AT_import      : <0x3b>   [Abbrev Number: 4 (DW_TAG_class_type)]
> ...

This case is different.  Full relevant DWARF part dump of it:
    < c>   DW_AT_producer    : (indirect string, offset: 0x0): GNU C++ 4.4.0 20090506 (Red Hat 4.4.0-4)
 <3><8c>: Abbrev Number: 9 (DW_TAG_imported_declaration)
    <8f>   DW_AT_import      : <0x3b>   [Abbrev Number: 4 (DW_TAG_class_type)]
 <1><3b>: Abbrev Number: 4 (DW_TAG_class_type)
    <3c>   DW_AT_specification: <0x36>
    <40>   DW_AT_byte_size   : 4
 <2><36>: Abbrev Number: 3 (DW_TAG_class_type)
    <37>   DW_AT_name        : B
    <39>   DW_AT_declaration : 1
(removed DW_AT_decl_file, DW_AT_decl_line, DW_AT_sibling in this mail)

Results in:
	die = <8c>
	imported_die = <3b>
	imported_name = "B"
so the import gets processed, doesn't it?  Do you have a reproducer of
incorrect GDB behavior?


That code:
+  if (imported_name == NULL)
+    {
+      /* C++ imports from std:: DW_TAG_base_type with no DW_AT_name - why?  */
+      return;
+    }

was there to handle the case I can find in (in fact arbitrary C++ code):
firefox-debuginfo-3.5-0.20.beta4.fc11.x86_64
/usr/lib/debug/usr/lib64/firefox-3.5b4/components/libbrowsercomps.so.debug
    < c>   DW_AT_producer    : (indirect string, offset: 0x121d): GNU C++ 4.4.0 20090427 (Red Hat 4.4.0-3)
 <1><e6d>: Abbrev Number: 48 (DW_TAG_namespace)
    <e6e>   DW_AT_name        : std
    <e74>   DW_AT_sibling     : <0xe87>
 <2><e78>: Abbrev Number: 49 (DW_TAG_imported_declaration)
    <e7b>   DW_AT_import      : <0xe87> [Abbrev Number: 6 (DW_TAG_base_type)]
 <1><e87>: Abbrev Number: 6 (DW_TAG_base_type)
    <e88>   DW_AT_byte_size   : 8
    <e89>   DW_AT_encoding    : 5       (signed)

In this case here is DW_AT_name in neither <e78> nor <e87>.  I still do not
understand meaning of the DIE <e78>.

Sure DIE <e87> is there to be referenced by other DIEs by its offset.  Just in
this file neither <e78> nor <e87> is referenced so they are IMO
excessive/unused there.  IIRC there is a GCC Bug for it but cannot find it.



On Tue, 16 Jun 2009 20:16:16 +0200, Tom Tromey wrote:
> >>>>> "Sami" == Sami Wagiaalla <swagiaal@redhat.com> writes:
> 
> Jan> I do not see a meaning of such import - if it has no name.  But this bug
> Jan> may be already covered by PR debug/14168 or possibly by PR debug/14169.
> 
> Sami> Is this a bug though. This imports the type specified by 0x50e keeping its
> Sami> name in the current context.
> 
> Yeah, see Dwarf 3 section 3.2.3.  It is clear about the meaning of a
> missing DW_AT_name in this situation.

DWARF3:
# An imported declaration may also have a DW_AT_name attribute whose value is
# a null-terminated string containing the name, as it appears in the source
# program, by which the imported entity is to be known in the context of the
# imported declaration entry (which may be different than the name of the
# entity being imported). If no name is present, then the name by which the
# entity is to be known is the same as the name of the entity being imported.  

DW_AT_name present at this DIE?
                     DW_TAG_imported_declaration  DW_TAG_base_type
A (invalid)          anonymous                    anonymous
B (standard import)  anonymous                    present
C (unhandled now)    present                      anonymous
D (renamed import)   present                      present

if (imported_name == NULL) catches A and C.  A should be caught as invalid.
It is true C should be parsed correctly but fortunately I do not know about
any existing DWARF files containing the C case (there may be some)

Sami's "namespace A" example above is the case B.

My case from firefox-debuginfo above is the case A.



Thanks,
Jan