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"


> To support C99 VLA, function value_from_contents_and_address() was
> modified to add a call to resolve_dynamic_type(), which in turn
> calls resolve_dynamic_array() to resolve the dynamic array bounds
> to static values. But the problem arises when function copy_type(),
> called by resolve_dynamic_array(), expects the type to be copied
> to have an associated objfile from which the new type is allocated,
> or asserts. Since type char[] doesn't have an associated objfile
> when the following gdb command:
> 
> (gdb) set {char[]}$pc="hello"
> 
> was issued, gdb asserts.
> 
> The gdb_assert (TYPE_OBJFILE_OWNED (type)) line in copy_type() doesn't
> look necessary or correct since space needed for the new type could be
> allocated from either the type's objfile if it exists or gdbarch if
> it doesn't, similar to what alloc_type_copy(), which is called after
> gdb_assert() in copy_type(), does. Removing gdb_assert() fixes the
> problem.

I think removing the assert just shifts the issue elsewhere.
Basically, you want the lifetime of the new type to match
the lifetime of the object using it. The gdbarch structure
has a lifetime that's different from objfiles.

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?

-- 
Joel


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