[PATCH] Allow writing to registers before the program starts

[PATCH] Allow writing to registers before the program starts

[Andrew STUBBS]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

Hi,

It used to be possible to write to registers before starting the program 
(on a simulator or other target that has registers that early). This is 
useful to start a program from a non-standard point, or else, with a 
target which retains it state between runs, reset the target to a usable 
state.

E.g:

(gdb) target sim
(gdb) load
(gdb) set $pc = 0x100

However, this now results in the message 'Value being assigned to is no 
longer active.'.

I have tracked this to a patch here: 
http://sourceware.org/ml/gdb-patches/2004-11/msg00317.html

Reverting the valops.c portion of this patch solves the problem for me. 
I have tested it and it produced no regressions.

Ok to apply the attached reversion?

Andrew

[-- Attachment #2: register-write.patch --]
[-- Type: text/plain, Size: 954 bytes --]

2006-05-03  Andrew Stubbs  <andrew.stubbs@st.com>

	* valops.c (value_assign): Revert Andrew Cagney's patch from
	2004-11-15:  re-allow writing of registers before there is
	a current frame.


Index: src/gdb/valops.c
===================================================================
--- src.orig/gdb/valops.c	2006-05-03 14:13:36.000000000 +0100
+++ src/gdb/valops.c	2006-05-03 14:14:28.000000000 +0100
@@ -610,8 +610,16 @@ value_assign (struct value *toval, struc
 	int value_reg;
 
 	/* Figure out which frame this is in currently.  */
-	frame = frame_find_by_id (VALUE_FRAME_ID (toval));
-	value_reg = VALUE_REGNUM (toval);
+	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);
+	  }
 
 	if (!frame)
 	  error (_("Value being assigned to is no longer active."));

Re: [PATCH] Allow writing to registers before the program starts

[Daniel Jacobowitz]

On Wed, May 03, 2006 at 03:02:43PM +0100, Andrew STUBBS wrote:
> Reverting the valops.c portion of this patch solves the problem for me. 
> I have tested it and it produced no regressions.
> 
> Ok to apply the attached reversion?

No, this patch is incorrect.  I don't recall exactly why, but I think
it will mess up writing to the saved registers after using "up".
I happen to know the actual cause of the problem you're trying to
fix; there's a nasty hack in CodeSourcery's branch to fix it, but
the real fix is more work than I've had time for yet.  It's a
representation problem.

As a starting point, here's my fix for the same problem:

Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.211
diff -u -p -r1.211 frame.c
--- frame.c	17 Dec 2005 22:33:59 -0000	1.211
+++ frame.c	2 Apr 2006 02:31:24 -0000
@@ -395,16 +395,26 @@ frame_find_by_id (struct frame_id id)
 {
   struct frame_info *frame;
 
+#if 0
   /* ZERO denotes the null frame, let the caller decide what to do
      about it.  Should it instead return get_current_frame()?  */
   if (!frame_id_p (id))
     return NULL;
+#endif
 
   for (frame = get_current_frame ();
        frame != NULL;
        frame = get_prev_frame (frame))
     {
       struct frame_id this = get_frame_id (frame);
+#if 1
+      /* We use an invalid frame id to mean "could not unwind from
+	 here"!  This hack fixes the "value being assigned to is
+	 no longer active" problem.  This strongly suggests that
+	 we need to change the representation.  */
+      if (!frame_id_p (id) && !frame_id_p (this))
+	return frame;
+#endif
       if (frame_id_eq (id, this))
 	/* An exact match.  */
 	return frame;


Basically, the problem comes about because we signal the end of the
stack by returning an invalid frame ID from ->this_id in the unwinder.
But we also use invalid IDs in various places to mean "no frame at all"
or "no frame in particular".  I think this causes trouble in other
places as well.  For instance you can't use outer/inner on the ID of
the last frame.

Sometimes, we don't have any idea what ID to use for the last frame. We
use the null ID in that case.  This is somewhat reasonable, but could
be problematic - we can't tell it apart from a completely different
frame that we can't unwind either.  The opposite could also be
problematic; using $sp might mean the frame ID changes unexpectedly
when we're within the same logical frame.  Maybe use a different
sentinal ID than the current one.

But it's the other case that I find more interesting.  A lot of the
times we know exactly what this frame's ID is, but have made a
conscious decision to stop unwinding (e.g. because the next frame's
stack pointer would be a sentinel value).  If we had a different
way to signal "stop unwinding here" but return a valid ID... I think
much of this awkwardness would go away.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Allow writing to registers before the program starts

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> No, this patch is incorrect.  I don't recall exactly why, but I think
> it will mess up writing to the saved registers after using "up".
> I happen to know the actual cause of the problem you're trying to
> fix; there's a nasty hack in CodeSourcery's branch to fix it, but
> the real fix is more work than I've had time for yet.  It's a
> representation problem.

OK, sorry. When I look at it more closely the patch doesn't do quite 
what I thought it did anyway.

This is all much more hideous than I had thought. I don't have either 
the time or the knowledge to fix the problem properly. Thanks for the 
hack - I'll just use that locally for the time-being.

Thanks

Andrew