[28/38] Move dwarf2_per_cu_data::imported_symtabs earlier
Commit Message
This moves dwarf2_per_cu_data::imported_symtabs earlier, near where
the other data members are located.
2020-01-22 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_cu_data) <imported_symtabs>:
Move earlier.
Change-Id: I314ddaa6f67c53a848e513b3f6d42913bd957833
---
gdb/ChangeLog | 5 +++++
gdb/dwarf2/read.h | 52 +++++++++++++++++++++++------------------------
2 files changed, 31 insertions(+), 26 deletions(-)
@@ -317,6 +317,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
{
@@ -347,32 +373,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. */