This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: fix PR c++/9197
- From: Doug Evans <dje at google dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 19 Mar 2013 10:12:27 -0700
- Subject: Re: RFC: fix PR c++/9197
- References: <87d2xcvjny dot fsf at fleche dot redhat dot com> <20130203052021 dot GA16948 at host2 dot jankratochvil dot net> <87wquo11ej dot fsf at fleche dot redhat dot com> <20130206195920 dot GA2797 at host2 dot jankratochvil dot net> <87y5dxpryn dot fsf at fleche dot redhat dot com>
On Fri, Mar 8, 2013 at 12:16 PM, Tom Tromey <tromey@redhat.com> wrote:
> Jan> I was briefly checking the code and while sometimes one must change
> Jan> also the callers / callers of callers etc. struct type * -> struct
> Jan> value * it should not be such a problem.
>
> Today I tried an approach like this. I added a new "lval_type" and
> changed a lot of code to use it.
>
> I like this, I think it is pretty clean. However the patch quickly grew
> very large, and I discovered that plenty of code exists that violates
> the reason I rejected my first approach:
>
> Tom> However, I'm no longer convinced it is safe, seeing how many other
> Tom> paths in eval.c avoid even memory reads for the
> Tom> EVAL_AVOID_SIDE_EFFECTS case.
>
> You can easily see memory reads using any path through binop_promote.
> For example if you have "short s; char c;", then "ptype s+c" will read
> memory. There are many of these.
>
> So now I'm leaning toward putting in my original fix.
For my own education, setting aside however broken gdb currently is,
what's the right answer?
IOW, how is ptype *defined* to work?
And, most importantly, is it possible to complete any missing pieces
of the definition (or at least write down our current best
understanding) so there's no more guesswork involved in the future?
One needn't think of memory mapped devices, one can just play with
mapped/unmapped memory (e.g. some memory may get unmapped after having
been mapped) or bad pointers. Also, is "ptype s+c" materially
different from "ptype *sptr+*cptr" ? (and do we want to impose any
distinction on the user?)
[Plus s and c could be in formerly mapped memory - should ptype s+c still work?]
I'm not sure I have a strong feeling on whether ptype should use
EVAL_NO_SIDE_EFFECTS or not, but if it should it feels like it should
be consistent.
Also, maybe have an option to ptype that specifies side-effects or not?
Interestingly, the online help of ptype says nothing about
expressions, need to fix that.
And now I'm wondering if we need a mechanism to distinguish the
ambiguity if "s" is a type and an expression.
E.g.
class s { public: int x; };
int s;
Also, for reference sake,
(gdb) p s
Attempt to use a type name as an expression
How do I print s the variable? [maybe there's a way but it escapes me]