[PP?] [RFA] internal-error using '@' (repeat) operator on array of dynamic objects

Joel Brobecker brobecker@adacore.com
Wed Jan 31 07:36:00 GMT 2018


> > 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



More information about the Gdb-patches mailing list