[RFC/RFA] Fix varobj.c value comparison problems
Daniel Jacobowitz
drow@false.org
Fri Feb 18 15:28:00 GMT 2005
On Thu, Feb 17, 2005 at 09:31:50PM -0500, Mark Kettenis wrote:
> Here's a patch for the problems with uninitialized floating-point
> varobj stuff I reported a few days ago. This patch introduces a new
> function value_contents_equal. That part is pretty "obvious",
> although one might argue that it should be put in valarith.c. I
> didn't put it there because this doesn't implement a C operator.
>
> The patch then changes my_value_equal in varobj.c to use that new
> function. I radically simplified the function. I think these
> simplifications are justified. The function is used to compare the
> old value of a variable with the new value of a variable. Therefore
> the value of VAR1 should already be known. I've put in a gdb_assert
> to make sure this is indeed the case. So we only have to deal with
> unlazying VAR2. Thus far, it seems that I'm right. This patch fixes
> the problems I was seeing and doesn't introduce any new failures.
>
> If nobody can shoot any holes in my reasoning, I'll check this in in a
> few days.
It sounds right to me.
> + type1 = check_typedef (value_type (val1));
> + type2 = check_typedef (value_type (val2));
> + len = TYPE_LENGTH (type1);
> + if (len != TYPE_LENGTH (type2))
> + return 0;
Should we just require equal types? I can't think of a real example,
but hypothetically, if we had a language with tagged unions:
int kind;
union { int a; float b; } u __attribute__((tagged(kind)))
and "kind" changed, thereby changing u from "0x80000000" to "whatever
that is as a single-precision float", the client would probably want to
update its display.
--
Daniel Jacobowitz
CodeSourcery, LLC
More information about the Gdb-patches
mailing list