This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: fix PR c++/9197
On Mon, 04 Feb 2013 17:36:52 +0100, Tom Tromey wrote:
> The difficulty here is that it is unclear whether lookup_struct_elt_type
> must necessarily parallel value_struct_elt.
I was thinking also about the archer-jankratochvil-vla branch remake where in
general case struct type * without / instead of struct value * is invalid.
> 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?
I more believe that if you have
struct foo **var = (void *) 0xdeadf00d; // pointer to unmapped memory
(gdb) ptype **var
then it should work while with value_struct_elt it would not; (or rather
a dereference through pointer stored in struct member).
> 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.
I was briefly checking the code and while sometimes one must change also the
callers / callers of callers etc. struct type * -> struct value * it should
not be such a problem.
Jan