Re: [RFA 1/2] Allocate dwarf2_per_cu_data and signatured_type with new

[Simon Marchi <simark at simark dot ca>]

On 2018-05-19 04:37 PM, Tom Tromey wrote:
> This changes dwarf2_per_cu_data and signatured_type to be allocated
> with new, rather than on the obstack.  The main idea here is to move
> destructors into the objects that actually own the data, to make
> dwarf2read a bit simpler to understand, and to enable the next patch.
> 
> This particular change required one little hack to make "delete" work
> properly.  I did not think it would be good to add a virtual
> destructor to dwarf2_per_cu_data just for this.

Hi Tom,

It would only be useful to make the destructor of dwarf2_per_cu_data virtual
if other classes (such as signatured_type) inherited from it instead of
including it as their first data member.  But I think it would be preferrable
to do that (inheritance + virtual destructor) instead of hacking our way around
like this.

I have a patch in a branch that does that:
https://github.com/simark/binutils-gdb/commit/bbbd2c0b10b6e78965cdd70a157e7f475522009f

Though I would get rid of the allocation on the obstack like you did.  Do you think it
would be a good way to go?  Or does the extra space used by the vtable for each CU
worries you?

In any case, I pushed my obstack_new stuff, because I presumed there would be
some problem here.  This allocation in create_type_unit_group is problematic:

  tu_group = OBSTACK_ZALLOC (&objfile->objfile_obstack,
			     struct type_unit_group);

because type_unit_group includes a dwarf2_per_cu_data, which now needs to be
constructed.  That class would also need to be new'ed.

Thanks,

Simon