Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Fallout from value changes?
@ 2004-11-14 15:47 Mark Kettenis
  2004-11-14 20:41 ` Mark Kettenis
  0 siblings, 1 reply; 3+ messages in thread
From: Mark Kettenis @ 2004-11-14 15:47 UTC (permalink / raw)
  To: cagney; +Cc: gdb

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}}

I strongly suspect this to be fallout from one of your recent value
changes.  Can you hold off any further changes until we've tracked
this down please?

Mark


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Fallout from value changes?
  2004-11-14 15:47 Fallout from value changes? Mark Kettenis
@ 2004-11-14 20:41 ` Mark Kettenis
  2004-11-16  0:37   ` Andrew Cagney
  0 siblings, 1 reply; 3+ messages in thread
From: Mark Kettenis @ 2004-11-14 20:41 UTC (permalink / raw)
  To: cagney; +Cc: gdb

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Fallout from value changes?
  2004-11-14 20:41 ` Mark Kettenis
@ 2004-11-16  0:37   ` Andrew Cagney
  0 siblings, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2004-11-16  0:37 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb

I committed the obvious fix - delete more code.  However ..

> Please revert the patch above, or fix this properly.

... since I'm clearly ``fixing this properly'' - thats what struct value 
and struct location are about - I'm left wondering why this tone was 
required.

Andrew


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-11-15 23:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-14 15:47 Fallout from value changes? Mark Kettenis
2004-11-14 20:41 ` Mark Kettenis
2004-11-16  0:37   ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox