This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC/RFA] Fix varobj.c value comparison problems
- From: Daniel Jacobowitz <drow at false dot org>
- To: Mark Kettenis <kettenis at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 17 Feb 2005 21:46:44 -0500
- Subject: Re: [RFC/RFA] Fix varobj.c value comparison problems
- References: <200502180231.j1I2VohT030718@copland.sibelius.xs4all.nl>
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