This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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




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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]