Re: Help needed with browsing GDB code

[Nityananda <j dot nityananda at gmail dot com>]

Hi Everyone,
One more question that i wanted to ask was: How can we find out when  
we have reached the end of the local variable allocation on the stack?  
Is there any other information which is going to be stored in the  
stack frame other than the return address, saved stack frame pointer  
and the local variables? So, is it true if we say that the end of the  
current stack frame is reached when we finish all the local variable  
allocation for that function? Registers from the caller are going to  
be stored in the previous stack frame, right?

Thanks and regards,
Nityananda

On Feb 18, 2009, at 9:17 PM, Nityananda wrote:

> Hi Everyone,
> Thanks for the information. Can you please help me out with more  
> questions?
> I am not sure how I can find the starting offset from the stack  
> frame pointer for the local variables on the frame. Can you please  
> tell me how I can find it in GDB code for the i386 architecture.
> Also how can i find the same information about the location of the  
> local variables when using fomit-frame-pointer compiler flag. Since  
> the frame pointers are no longer going to be in the stack frames.
>
> Thanks and regards,
> Nityananda
>
> On Feb 7, 2009, at 6:06 AM, Ramana Radhakrishnan wrote:
>
> > Hi Nityananda,
> >
> >
> > On Sat, Feb 7, 2009 at 1:52 AM, Nityananda <j.nityananda@gmail.com>  
> > wrote:
> > > HI Thiago,
> > > Thanks for the information. I am reading the code to deal with the  
> > > stack
> > > frame information without the debug information. Can you please  
> > > point me to
> > > the code with the debug information? You mentioned that it uses  
> > > DWARF2.
> >
> > Look at gdb/dwarf2-frame.c for DWARF2 frame reading .
> >
> > > So are the local variables always at the same offset of the frame  
> > > base address
> > > or there is a possibility of these addresses changing from one  
> > > process to
> > > another?
> >
> > Local variables will always be at the same offset from the frame base
> > address for the same program unless you have self modifying code .
> > Operating Systems 101 - A process can be multiple instantiations of
> > the same program.
> >
> > HTH
> >
> > cheers
> > Ramana
> >
> > > Thank you very much in advance,
> > > Nityananda
> > >
> > > On Feb 6, 2009, at 4:01 AM, Thiago Jung Bauermann wrote:
> > >
> > > > Hi Nityananda,
> > > >
> > > > El jue, 05-02-2009 a las 18:26 -0800, Nityananda escribió:
> > > > > I am looking for how
> > > > > GDB obtains the address of stack local variables. I am seeing some
> > > > > code related to frame_info but do not know how it actually works.
> > > >
> > > > Well, there are two situations: with debug information available,  
> > > > and
> > > > without. For the first case it's simple: the DWARF2 format  
> > > > includes the
> > > > frame base address as part of the unwind information, and  
> > > > addresses of
> > > > local variables in the debuginfo are relative to that base address.
> > > >
> > > > When there's no debuginfo available, GDB uses its knowledge of  
> > > > the OS
> > > > ABI for the given architecture. For example, for ppc64-linux, the  
> > > > stack
> > > > frame layout is given here:
> > > >
> > > > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#STACK
> > > >
> > > > And the code which uses that knowledge is in
> > > > rs6000-tdep.c:rs6000_frame_cache. It's kinda hairy...
> > > > --
> > > > []'s
> > > > Thiago Jung Bauermann
> > > > IBM Linux Technology Center