This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: View registers from stack frames


On Fri, 08 Oct 2004 10:54:34 +0200
Fabian Cenedese <Cenedese@indel.ch> wrote:

> >> In frame 0 pc and lr are correct (different), but in the other frames
> >> they always have the same value whereas lr should have the
> >> value of the pc of the next frame, right?
> >
> >Recent versions of GDB show the same value for lr and pc for the later
> >frames.  I think this is okay.
> >
> >Kevin
> 
> I have only tested the --target=powerpc-eabi version so I don't know about
> other processors. Is this true that gdb is supposed to show pc and lr with
> the same values for stack frames >0? Isn't the purpose of the lr to point
> to the previous stack frame (and so be different from the actual pc)?
> And if the actual behaviour is correct then why is it different for frame 0?

I agree that this seems counter-intuitive, particularly after working
with it behaving the "other" way for so long.

If you set a breakpoint at the start of a function and the run until that
breakpoint, you'll find that LR does indeed point to the address at which
execution will continue when the current function returns in a normal
manner.  PC will be the address of the instruction at which you've
stopped.  These values should be different.

Now, suppose you step through the function until you reach a call.  If
you step over that call and examine PC and LR, you'll find that they
have the same value.  Why is this so?  It's because the "call" (bl)
instruction puts pc+4 into LR and branches to the function.  Since
you've stepped over the function, and since LR is restored in that
function's prologue, you'll find that LR contains the address at which
you're currently stopped which is in fact the current PC value.

Those lower frames are in the same situation that our top-most frame
is in in the second case.  A "call" was the last instruction to be
executed in that frame; this means that the LR value is actually set to
the value of the PC just after the call.

Looking at it another way, the reason that PC and LR are the same
value for frames other than the topmost frame (excluding possible
sigtramp frames, where they may in fact be different), is because LR
changes over the lifetime of the function.  GDB is reporting this as
accurately as it can.

Kevin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]