Re: [PATCH PR gdb/20057] Internal error on trying to set {char[]}$pc="string"

[Wei-min Pan <weimin dot pan at oracle dot com>]

On 11/29/2018 1:52 PM, Tom Tromey wrote:
> > > > > > ">" == Wei-min Pan <weimin.pan@oracle.com> writes:
> > > Looks like we have at least 2 options:
> > > (1) Making sure the type is objfile-owned before calling copy_type in
> > > resolve_dynamic_range and resolve_dynamic_array as you suggested, or
> > > (2) Replacing the assert with an objfile-owned check in copy_type, similar
> > > to what copy_type_recursive does.
> Sorry, I still didn't read the whole thread... but I think what to do
> depends on what is happening.
>
> Most callers of copy_type are probably copying it to modify the copy.
> If this is the case, then maybe just removing the assert is ok.
> Or, maybe it makes sense to understand why the modified type isn't
> objfile-allocated in the first place.
>
> Could you recap?  What is calling copy_type here and where did the type
> come from?
>
> Tom

Let's use an example:

(gdb) p {char []}$pc

if the element type "char" is defined in the program, i.e. it has an 
objfile,
lookup_array_range_type sets the "index type" with that objfile's 
builtin_int.
Otherwise, it sets it with gdbarch's built-in. The index type is then used
to create the range type and the array type. Thus the array type is entirely
either objfile-owned or gdbarch-owned.

Both resolve_dynamic_array and resolve_dynamic_range call copy_type to
allocate a type and yes modify it to represent a static version of the array
type from lookup_array_range_type() above.