This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: fix PR c++/9197
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 04 Feb 2013 09:36:52 -0700
- Subject: Re: RFC: fix PR c++/9197
- References: <87d2xcvjny.fsf@fleche.redhat.com> <20130203052021.GA16948@host2.jankratochvil.net>
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> On Thu, 10 Jan 2013 21:59:29 +0100, Tom Tromey wrote:
>> The PR doesn't really show any symptoms of the bug -- it is one of the
>> "cleanup" bugs that remain open in bugzilla -- but PR 11463 shows the
>> problem nicely: "print test1.gnu_obj_1" shows something, but "ptype" of
>> the same expression yields an error.
Jan> This means lookup_struct_elt_type has bug(s). After your patch it
Jan> is only used in ada-lang.c and p-exp.c so a TODO item is to convert
Jan> those calls also to value_struct_elt. Therefore
Jan> lookup_struct_elt_type could be at least renamed to
Jan> deprecated_lookup_struct_elt_type.
The difficulty here is that it is unclear whether lookup_struct_elt_type
must necessarily parallel value_struct_elt.
One option is to do what I did. However, I'm no longer convinced it is
safe, seeing how many other paths in eval.c avoid even memory reads for
the EVAL_AVOID_SIDE_EFFECTS case. Perhaps this is for memory-mapped
devices?
Another option is to fix lookup_struct_elt_type. Maybe this was the
intent and is safe. Or maybe not.
A third approach is to make a new function which by intent parallels
value_struct_elt, then use it.
I lean toward #3, but mostly because I don't know the Ada or Pascal code
in gdb well enough to say which may be truly correct.
Tom