This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Fallout from value changes?
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: cagney at gnu dot org
- Cc: gdb at sources dot redhat dot com
- Date: Sun, 14 Nov 2004 16:46:57 +0100 (CET)
- Subject: Re: Fallout from value changes?
- References: <200411141437.iAEEbiCc010466@elgar.sibelius.xs4all.nl>
Replying to my onw message:
Date: Sun, 14 Nov 2004 15:37:44 +0100 (CET)
From: Mark Kettenis <kettenis@gnu.org>
Hi Andrew,
I noticed this new testsuite failure on i386-unknown-freebsd4.7:
-PASS: gdb.base/store.exp: up struct 4 u; print new u, expecting {s = \{1, 2, 3, 4}}
+FAIL: gdb.base/store.exp: up struct 4 u; print new u, expecting {s = \{1, 2, 3, 4}}
This is caused by this patch:
2004-11-12 Andrew Cagney <cagney@gnu.org>
* defs.h (enum lval_type): Delete lval_reg_frame_relative.
* value.h (struct value): Update comment.
* valops.c (value_assign): Fold lval_reg_fame_relative into
lval_register.
* findvar.c (value_from_register, locate_var_value): Ditto.
which breaks valops.c:value_assign(). That function contains the
following bit of code:
case lval_register:
{
struct frame_info *frame;
int value_reg;
/* Figure out which frame this is in currently. */
if (VALUE_LVAL (toval) == lval_register)
{
frame = get_current_frame ();
value_reg = VALUE_REGNUM (toval);
}
else
{
frame = frame_find_by_id (VALUE_FRAME_ID (toval));
value_reg = VALUE_REGNUM (toval);
}
The if statement doesn't make sense; it's always true. As a result
the function will never do proper frame-relative assigns. Simply
removing the if-clause isn't a good solution since that will break
assigning to non-frame-relative register variables. I guess we'll
have to change GDB such that it always initializes VALUE_FRAME_ID to
say null_frame_id, and using get_current_frame() in that case.
Please revert the patch above, or fix this properly.
Mark