[review] Test making delayed_method_info vectors local variables

[Simon Marchi (Code Review)]

Simon Marchi has posted comments on this change.

Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/128
......................................................................


Patch Set 1:

> Patch Set 1:
> 
> FWIW I think the idea is that `dwarf2_cu` should exist just to hold
> temporary data that's used when reading a CU -- and then be discarded.
> So, in effect, it should already be a form of local variable.
> 
> Whether or not it works this way in practice is hard to tell, because
> dwarf2read has a spaghetti-like nature.  It would be great to clean
> all this up (say, replace things like `init_cutu_and_read_dies` with
> a constructor), but of course that's a big job.

The problem with dwarf2_cu is that it's attached to a particular CU.  So when we read a CU A, which then imports some stuff from CU X, the dwarf2_cu attached to A doesn't follow.  But for things like the delayed method info vector, we want to keep working with the data structure we created when we started reading A.  So it's not really attached to A or X, it's attached to the current operation of reading A.

Here is the context, in case you haven't read it:

  https://sourceware.org/ml/gdb-patches/2019-10/msg00547.html

This is a proof of concept, I need to go over it again.  Maybe I'll find out that actually everything in dwarf2_cu should be treated the same way as the delayed method info.