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

[Joel Brobecker <brobecker@adacore.com>]

> Is there any reason why the gdbarch structure, which won't be freed
> until the corresponding architecture is, needs to have a lifetime that
> matches the objfiles?

Unfortunately, I only have vague answers for you. I know it's not
as satisfactory as a firm one, but I haven't had time to investigate
further.

My feeling is that it's (intuitively) a bad idea to start mixing
and matching the ownership type for a give type chain. It just
muddies the waters, and makes memory management more complex.

Parallel to that, there is another obstacle if you want to enhance
copy_type to handle arch-owned types, as the current implementation
explicitly assumes that the type is objfile-owned, and therefore
references its objfile's obstack:

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

> > I happen to have hit the same issue as you, but from an Ada expression,
> > and sent it a fix not long ago:
> > https://www.sourceware.org/ml/gdb-patches/2018-01/msg00240.html
> > 
> > Does it fix your problem too?
> > 
> Yes, it does fix my problem of gdb asserting on the "set {char[]}$pc="hi""
> command, as
> reported in the PR,

Good!

> but still asserts on a slightly modified "set {unsigned char[]}$pc="hi"
> command.

It's should be something fairly similar. Can you track down which type
it is which is arch-owned, and where it comes from? I have a feeling
that there is a simple fix similar to mine to be made that would
fix that.

I can help taking a look, but I'm a little tied up this week...

-- 
Joel