This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PP?] [RFA] internal-error using '@' (repeat) operator on array of dynamic objects
> > gdb/ChangeLog:
> >
> > * gdbtypes.c (lookup_array_range_type): Make sure the array's
> > index type is objfile-owned if the element type is as well.
> >
> > gdb/testsuite/ChangeLog:
> >
> > * testsuite/gdb.ada/dyn_stride.exp: Add "print a1(1)@3" test.
> I looked at this, more as a learning experience than anything else, but it
> looks good to me.
Thanks for having taken a look. I just pushed the patch to master.
> Any idea why copy_type only deals with objfile-owned types?
I am not sure, unfortunately. This comes from a patch pushed in Jul 2009:
https://www.sourceware.org/ml/gdb-patches/2009-06/msg00741.html
Subject: [6/7] Introduce per-type architecture
| The existing type allocation routines alloc_type and init_type
| now always create per-objfile types; it is now a bug to call
| them with a NULL objfile parameter. The helpers init_float_type,
| init_complex_type, init_flags_type, and init_composite_type are
| removed (and replaced by per-arch variants).
|
| There is new routine alloc_type_arch that allocates a non-
| objfile related type; you have to specify a (non-NULL) gdbarch
| argument instead. A number of helper routines are provided
| to simplify architecture-specific type creation (arch_type,
| arch_integer_type, arch_character_type, arch_boolean_type,
| arch_float_type, arch_complex_type, arch_flags_type, and
| arch_composite_type).
|
| Finally, if you want to allocate a new type with the same
| ownership information (objfile or architecture) as an existing
| type, you can use alloc_type_copy to do so.
|
| The patch goes through all remaining places in GDB that allocate
| types and makes sure the appropriate allocation routine is used.
One thing I can say is that, since that patch was pushed, we later on
added some code which assumes the type is objfile-owned:
if (TYPE_DYN_PROP_LIST (type) != NULL)
TYPE_DYN_PROP_LIST (new_type)
= copy_dynamic_prop_list (&TYPE_OBJFILE (type) -> objfile_obstack,
TYPE_DYN_PROP_LIST (type));
Interestingly, a contributor sent a patch to remove that assertion,
and I was hoping my patch would fix his problem, but only partially.
https://www.sourceware.org/ml/gdb-patches/2018-01/msg00494.html
He's asking questions about lifetime and implicitly why we can't
mix-and-match ownership types, and besides a vague "I don't think
this is a good idea / this is an added risk / might make it harder
to eliminate one objfile if we want to use a different memory
management system", I don't know what to answer.
I will send a first answer nonetheless. Comments on that thread
always welcome.
--
Joel