Help needed with browsing GDB code

Help needed with browsing GDB code

[Nityananda]

Hi,
My name is Nityananda. I am reading the source code of GDB and was  
stuck unable to find a certain part of the code. 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. I am  
also looking at the GDB internals document but it does not have  
information to the level of granularity that I need.
Can someone please help me find the exact code that is used for  
reading the address of the stack local variables.
I plan to write some code that is similar to GDB's in order to find  
the location of stack local variables of a running program.


Thanks and regards,
Nityananda

Re: Help needed with browsing GDB code

[Thiago Jung Bauermann]

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

Re: Help needed with browsing GDB code

[Nityananda]

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

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
>

Re: Help needed with browsing GDB code

[Ramana Radhakrishnan]

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

Re: Help needed with browsing GDB code

[Ramana Radhakrishnan]

Hi Nityananda,

Please don't top post - Thanks.

On Sat, Feb 7, 2009 at 10:13 PM, Nityananda Jayadevaprakash
<j.nityananda@gmail.com> wrote:
> Hi Ramana,
> Thanks a lot for pointing me in the right direction. I will look at the code
> now.....i was wondering whether the local variables are always at the same
> offset from the frame address since there are some measures of security now
> like stack randomization and stack guards  along with address space layout
> randomization...Thank you for the clarification though.

However the offsets to local variables from the frame pointer or the
stack pointer will be a constant at compile time or describable in the
debug information.  Address space randomization right now works on
giving random addresses to different loadable modules but it is
essentially the virtual address where the loaded module is mapped in
v.m  . The stack randomization works by giving non-deterministic base
addresses to the stack pointer - again at program load time.


> One more clarification required please: In the stack frame, since the
> register ebp contains the address of the stack frame, how can we get to an
> outer frame when there is no information in this current frame which points
> us to the previous frame? The GDB internals page says that the previous page
> can be reached from the next younger frame, but using what pointer/register?
> Please help

A frame in gdb parlance is defined as a combination of a PC value and
a pointer into the stack which holds the activation record for that
particular function.  Note that ebp in this case on the x86 points to
the location in stack where the previous stack's frame pointer is
stored. Assuming the stack grows downwards - the memory location
[ebp+4] has the return address for the calling frame.If you look at
code generated and work out the values on the call stack you will be
able to see this information.

Assuming this recursively you can see how to unwind the stack easily.

A point to remember is that this is similar to the mechanism the
program uses in order to return from function calls, the only
difference being the debugger working out these values when the
debuggee is stopped.


cheers
Ramana



>
> Thanks and regards,
> Nityananda
>
>
> On Sat, Feb 7, 2009 at 6:06 AM, Ramana Radhakrishnan <ramana.r@gmail.com>
> 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
>> >>
>> >
>> >
>
>

Re: Help needed with browsing GDB code

[Nityananda]

Hi Ramana,
Thanks for that insightful mail.
I however have more questions about how GDB works. I would really  
appreciate it if you could explain how it works along with pointers  
into the code.

How are the local variables found when the gcc is used with the fomit- 
frame-pointer flags?

Thanks and regards,
Nityananda

On Feb 7, 2009, at 9:17 AM, Ramana Radhakrishnan wrote:

> Hi Nityananda,
>
> Please don't top post - Thanks.
>
> On Sat, Feb 7, 2009 at 10:13 PM, Nityananda Jayadevaprakash
> <j.nityananda@gmail.com> wrote:
>> Hi Ramana,
>> Thanks a lot for pointing me in the right direction. I will look at  
>> the code
>> now.....i was wondering whether the local variables are always at  
>> the same
>> offset from the frame address since there are some measures of  
>> security now
>> like stack randomization and stack guards  along with address space  
>> layout
>> randomization...Thank you for the clarification though.
>
> However the offsets to local variables from the frame pointer or the
> stack pointer will be a constant at compile time or describable in the
> debug information.  Address space randomization right now works on
> giving random addresses to different loadable modules but it is
> essentially the virtual address where the loaded module is mapped in
> v.m  . The stack randomization works by giving non-deterministic base
> addresses to the stack pointer - again at program load time.
>
>
>> One more clarification required please: In the stack frame, since the
>> register ebp contains the address of the stack frame, how can we  
>> get to an
>> outer frame when there is no information in this current frame  
>> which points
>> us to the previous frame? The GDB internals page says that the  
>> previous page
>> can be reached from the next younger frame, but using what pointer/ 
>> register?
>> Please help
>
> A frame in gdb parlance is defined as a combination of a PC value and
> a pointer into the stack which holds the activation record for that
> particular function.  Note that ebp in this case on the x86 points to
> the location in stack where the previous stack's frame pointer is
> stored. Assuming the stack grows downwards - the memory location
> [ebp+4] has the return address for the calling frame.If you look at
> code generated and work out the values on the call stack you will be
> able to see this information.
>
> Assuming this recursively you can see how to unwind the stack easily.
>
> A point to remember is that this is similar to the mechanism the
> program uses in order to return from function calls, the only
> difference being the debugger working out these values when the
> debuggee is stopped.
>
>
> cheers
> Ramana
>
>
>
>>
>> Thanks and regards,
>> Nityananda
>>
>>
>> On Sat, Feb 7, 2009 at 6:06 AM, Ramana Radhakrishnan <ramana.r@gmail.com 
>> >
>> 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
>>>>>
>>>>
>>>>
>>
>>

Re: Help needed with browsing GDB code

[Nityananda]

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

Re: Help needed with browsing GDB code

[Nityananda]

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