[PATCH 07/14] Add dwarf2_per_cu_data::index

[Simon Marchi]

On 2020-02-15 11:54 a.m., Tom Tromey wrote:
> @@ -255,6 +266,10 @@ public:
>    /* CUs that are queued to be read.  */
>    std::queue<dwarf2_queue_item> queue;
>  
> +  /* The total number of per_cu and signatured_type objects that have
> +     been created for this reader.  */
> +  size_t num_psymtabs = 0;

Make this private, and name it m_num_psymtabs?

> +
>    /* State that cannot be shared across objfiles.  This is normally
>       nullptr and is temporarily set to the correct value at the entry
>       points of the reader.  */
> @@ -336,6 +351,9 @@ struct dwarf2_per_cu_data
>       This flag is only valid if is_debug_types is true.  */
>    unsigned int tu_read : 1;
>  
> +  /* Our index in the unshared "all_cutus" vector.  */
> +  unsigned index;

The "all_cutus" vector does not exist (at least at the moment, maybe it's added later
in the series?).  I presume you are talking about the logical/combined vector made of
all_comp_units and all_type_units, accessible using dwarf2_per_objfile::get_cutu?

This logical/combined vector has all the comp units first, then the type units.  Using
the new interface allocate_per_cu/allocate_signatured_type, the indices are handed out
in any order.  I don't know if it's actually possible to have it in this order, but let's
say we read:

- a CU
- a TU
- a CU

The CUs will have been handed out indices 0 and 2, and the TU will have been handed out
index 1.  But in reality, when accessing them using get_cutu, the two CUs will be at 0 and
1, while the TU will be at 2.  Again, not sure if it matters, but I thought I would point
it out.

Or maybe this is what you meant by "the index here is weird since it may not (!?!?) be the
same as the other index", this is not the same index?  I guess I'll read the rest of the
series and find out.

Simon