This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 1/2] Allocate dwarf2_per_cu_data and signatured_type with new
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