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: RFC: fix PR c++/9197


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


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