This is the mail archive of the gdb@sourceware.org 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: Help needed with browsing GDB code


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







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