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

Wei-min Pan
2018-11-15T00:16:05Z

On 11/14/2018 3:51 PM, Joel Brobecker wrote:
>>>>> 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.
>>>> Given there are functions such as arch_integer_type(),
>>>> arch_character_type(),
>>>> and arch_float_type() that can be used to add types to an arch, it doesn't
>>>> seem terribly wrong to add a type which is not associated with any objfile
>>>> to gdbarch? Also a type can actually exist in both an arch and an objfile.
>>> I am not sure we understand each other. For me, what seems wrong
>>> is the fact that we have an array type where part of the type is
>>> objfile-owned, and part of it arch-owned.
>>>
>>> Creating arch-owned type is fine, as long as the entire type is
>>> arch-owned.
>> Sorry, I just don't see how it's possible to have an array type where
>> part of the type is objfile-owned and part of it arch-owned. When an
>> array type is copied, the space allocation depends on whether or not
>> the element type is defined in the program. If it is defined, space
>> for the index type, range type, and array type itself are all
>> allocated from that object file. Otherwise, they are all allocated
>> from the arch.
> I am not sure I understand what you are saying. On my end, I am
> precisely saying that we should not create a type where we have
> a mix and match. And if I read this last message correctly, you
> are saying you don't see how it's possible to be doing that. So,
> on the surface, your last message seems to be in agreement with
> the property I am saying we should preserve. But aren't you reporting
> a situation where we are actually trying to create a type with
> inconsistent ownership? Otherwise, I don't see why we would have
> triggered the assertion failure you reported.
>

Problem is copy_type will assert on to-be-copied type which does not
have an
associated objfile. It doesn't matter if the type is entirely arch-owned.