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: Fri, 08 Mar 2013 13:16:48 -0700
- Subject: Re: RFC: fix PR c++/9197
- References: <87d2xcvjny.fsf@fleche.redhat.com> <20130203052021.GA16948@host2.jankratochvil.net> <87wquo11ej.fsf@fleche.redhat.com> <20130206195920.GA2797@host2.jankratochvil.net>
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.
Tom