info on "value being assigned to is no longer active" error

When writing to a register (msr) when the stack pointer or
PC is
corrupt, gdb throws out the following error:

----
(gdb) p/x $rmsr
{ frame_register_unwind (frame=-1,regnum=33(rmsr),...)
->
*optimizedp=0 *lvalp=2 *addrp=0x84 *bufferp=[000000a0] }
{ get_frame_id (fi=0) { frame_func_unwind (fi=-1) -> 0x0
}
-> {!stack,!code,!special} }
$1 = 0xa0

(gdb) set $rmsr=0x0
{ frame_register_unwind (frame=-1,regnum=33(rmsr),...)
->
*optimizedp=0 *lvalp=2 *addrp=0x84 *bufferp=[000000a0] }
{ frame_id_p (l={!stack,!code,!special}) -> 0 }
Value being assigned to is no longer active.
-----

This sounds pretty similar to the issue reported here:
ht
tp://sourceware.org/ml/gdb/2005-05/msg00029.html

What I do not understand is why gdb is looking for a proper
frame
before updating the register.

If my (admittedly cursory) examination of the code in
valops.c is
correct, it appears as if gdb is looking for the frame to
make sure
that it updates the value of the register if it has been
stored in the
stack. Is that correct?

Thanks,
Siva
-- 
In the end, everything is a gag.
           Charlie Chaplin

On Fri, Jan 18, 2008 at 08:11:34PM -0800, Siva Velusamy
wrote:
> If my (admittedly cursory) examination of the code in
valops.c is
> correct, it appears as if gdb is looking for the frame
to make sure
> that it updates the value of the register if it has
been stored in the
> stack. Is that correct?

Roughly.  All registers in GDB belong to a frame.  Either
the current
frame or a saved stack frame.  GDB has found the current
frame, but
confuses its ID with an invalid frame marker.

-- 
Daniel Jacobowitz
CodeSourcery

On Jan 18, 2008 8:21 PM, Daniel Jacobowitz <drowfalse.org> wrote:
> On Fri, Jan 18, 2008 at 08:11:34PM -0800, Siva Velusamy
wrote:
> > If my (admittedly cursory) examination of the code
in valops.c is
> > correct, it appears as if gdb is looking for the
frame to make sure
> > that it updates the value of the register if it
has been stored in the
> > stack. Is that correct?
>
> Roughly.  All registers in GDB belong to a frame. 
Either the current
> frame or a saved stack frame.  GDB has found the
current frame, but
> confuses its ID with an invalid frame marker.
>

Thanks. Should gdb be able to handle this correctly, or is
this a
situation where it is tough to define the correct course of
action?

If gdb should handle this, what sort of change would be
appropriate in
the target specific code?

Siva

On Fri, Jan 18, 2008 at 08:26:17PM -0800, Siva Velusamy
wrote:
> Thanks. Should gdb be able to handle this correctly, or
is this a
> situation where it is tough to define the correct
course of action?
> 
> If gdb should handle this, what sort of change would be
appropriate in
> the target specific code?

The problem is not a target-specific one.  I know I've
discussed the
appropriate fix on the list at some point in the past two
years; the
problem arises because we use null_frame_id as the ID of the
outermost
real frame and to mark invalid frames.

The simplest fix might be to introduce another invalid frame
ID and
use that for outermost frames.  A better fix would be to
always use
valid frame IDs, and mark non-unwindable frames some other
way.

-- 
Daniel Jacobowitz
CodeSourcery