This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH PR gdb/20057] Internal error on trying to set {char[]}$pc="string"
- From: Wei-min Pan <weimin dot pan at oracle dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org
- Date: Thu, 29 Nov 2018 13:10:19 -0800
- Subject: Re: [PATCH PR gdb/20057] Internal error on trying to set {char[]}$pc="string"
- References: <1516844738-79996-1-git-send-email-weimin.pan@oracle.com> <20180125041431.tghhxefsgxnxh3l3@adacore.com> <1dfc87b0-353d-3388-a427-fee247dc79a5@oracle.com> <20180131074526.rqbsjxyxp3p26js5@adacore.com> <1d28e9c6-6377-0c46-6bce-1dc25a7fa2d5@oracle.com> <20180201075955.mnqxzmw4ktuy3f5d@adacore.com> <bdd471e6-8568-e675-1e07-6f5424fc8907@oracle.com> <20181114235153.GB4336@adacore.com> <ba98506a-766b-2353-7ff7-03a90746ecc3@oracle.com> <87tvjzae0u.fsf@tromey.com>
On 11/29/2018 11:18 AM, Tom Tromey wrote:
">" == Wei-min Pan <weimin.pan@oracle.com> writes:
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.
I didn't follow this thread in too much detail, but FWIW I believe the
rule is that an objfile-owned type can refer to a gdbarch-owned type --
but not vice versa.
Following that it seems to me that there should not be a need to call
copy_type on a gdbarch-owned type. So maybe that can be avoided,
instead of removing the assert?
Tom
Looks like we have at least 2 options:
(1) Making sure the type is objfile-owned before calling copy_type in
resolve_dynamic_range and resolve_dynamic_array as you suggested, or
(2) Replacing the assert with an objfile-owned check in copy_type, similar
to what copy_type_recursive does.