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


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

Thanks for your extensive explanation, it looks more clear now why
it is the way it is. The value I assumed to be in LR (PC in last frame)
is still reported from gdb as "saved PC". Is there another possibility
to get this value than the stack frame info? Is this maybe stored in
some gdb internal variable?

Thanks

bye  Fabi



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