This is the mail archive of the archer@sourceware.org mailing list for the Archer 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]

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


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);
> +  if (imported_name == NULL)
> +    {
> +      /* C++ imports from std:: DW_TAG_base_type with no DW_AT_name - why?  */
> +      return;
> +    }

As discussed on the meeting call the reasons for this exception:

#include <iostream>
using namespace std;
int main () { return 0; }

g++ -g -o std std.C 
gcc-4.3.2-3.x86_64

I get 37KB of ELF with:

(1) Many never-used DW_TAG_imported_declaration DIEs - IMO GCC PR debug/14168.

    But they make some sense as one should be able to access std:: items at
    least from the debugger.
    
    They need to be defined in DWARF - we cannot import whole "std::" by
    a single DIE as the debugger does not parse the header files.  Still such
    imports should be shared across Compilation Units (by a tool doing
    -feliminate-dwarf2-dups right).

(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.


Regards,
Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]