Move dwarf2_per_cu_data::imported_symtabs earlier

This moves dwarf2_per_cu_data::imported_symtabs earlier, near where
the other data members are located.

2020-02-08  Tom Tromey  <tom@tromey.com>

	* dwarf2/read.h (struct dwarf2_per_cu_data) <imported_symtabs>:
	Move earlier.

Change-Id: I314ddaa6f67c53a848e513b3f6d42913bd957833
This commit is contained in:
Tom Tromey 2020-02-08 13:40:54 -07:00
parent 8fdd972c30
commit 96c738c02f
2 changed files with 31 additions and 26 deletions

View File

@ -1,3 +1,8 @@
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_cu_data) <imported_symtabs>:
Move earlier.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (dwarf_line_debug): Declare.

View File

@ -338,6 +338,32 @@ struct dwarf2_per_cu_data
struct dwarf2_per_cu_quick_data *quick;
} v;
/* The CUs we import using DW_TAG_imported_unit. This is filled in
while reading psymtabs, used to compute the psymtab dependencies,
and then cleared. Then it is filled in again while reading full
symbols, and only deleted when the objfile is destroyed.
This is also used to work around a difference between the way gold
generates .gdb_index version <=7 and the way gdb does. Arguably this
is a gold bug. For symbols coming from TUs, gold records in the index
the CU that includes the TU instead of the TU itself. This breaks
dw2_lookup_symbol: It assumes that if the index says symbol X lives
in CU/TU Y, then one need only expand Y and a subsequent lookup in Y
will find X. Alas TUs live in their own symtab, so after expanding CU Y
we need to look in TU Z to find X. Fortunately, this is akin to
DW_TAG_imported_unit, so we just use the same mechanism: For
.gdb_index version <=7 this also records the TUs that the CU referred
to. Concurrently with this change gdb was modified to emit version 8
indices so we only pay a price for gold generated indices.
http://sourceware.org/bugzilla/show_bug.cgi?id=15021.
This currently needs to be a public member due to how
dwarf2_per_cu_data is allocated and used. Ideally in future things
could be refactored to make this private. Until then please try to
avoid direct access to this member, and instead use the helper
functions above. */
std::vector <dwarf2_per_cu_data *> *imported_symtabs;
/* Return true of IMPORTED_SYMTABS is empty or not yet allocated. */
bool imported_symtabs_empty () const
{
@ -368,32 +394,6 @@ struct dwarf2_per_cu_data
delete imported_symtabs;
imported_symtabs = nullptr;
}
/* The CUs we import using DW_TAG_imported_unit. This is filled in
while reading psymtabs, used to compute the psymtab dependencies,
and then cleared. Then it is filled in again while reading full
symbols, and only deleted when the objfile is destroyed.
This is also used to work around a difference between the way gold
generates .gdb_index version <=7 and the way gdb does. Arguably this
is a gold bug. For symbols coming from TUs, gold records in the index
the CU that includes the TU instead of the TU itself. This breaks
dw2_lookup_symbol: It assumes that if the index says symbol X lives
in CU/TU Y, then one need only expand Y and a subsequent lookup in Y
will find X. Alas TUs live in their own symtab, so after expanding CU Y
we need to look in TU Z to find X. Fortunately, this is akin to
DW_TAG_imported_unit, so we just use the same mechanism: For
.gdb_index version <=7 this also records the TUs that the CU referred
to. Concurrently with this change gdb was modified to emit version 8
indices so we only pay a price for gold generated indices.
http://sourceware.org/bugzilla/show_bug.cgi?id=15021.
This currently needs to be a public member due to how
dwarf2_per_cu_data is allocated and used. Ideally in future things
could be refactored to make this private. Until then please try to
avoid direct access to this member, and instead use the helper
functions above. */
std::vector <dwarf2_per_cu_data *> *imported_symtabs;
};
/* Entry in the signatured_types hash table. */