Re: Help needed with browsing GDB code

[Ramana Radhakrishnan <ramana dot r at gmail dot com>]

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