This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
DW_TAG_imported_declaration DW_TAG_base_type w/o DW_AT_name [Re:using directive patch]
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Sami Wagiaalla <swagiaal at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>, Dodji Seketeli <dseketel at redhat dot com>
- Date: Thu, 18 Sep 2008 23:13:35 +0200
- Subject: DW_TAG_imported_declaration DW_TAG_base_type w/o DW_AT_name [Re:using directive patch]
- References: <48BED230.1070209@redhat.com> <20080907183612.GA7304@host0.dyn.jankratochvil.net>
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