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


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


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