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"


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

-- 
Joel


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