From: Ramana Radhakrishnan <ramana.r@gmail.com>
To: Nityananda <j.nityananda@gmail.com>
Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>, gdb@sourceware.org
Subject: Re: Help needed with browsing GDB code
Date: Sat, 07 Feb 2009 14:06:00 -0000 [thread overview]
Message-ID: <67ea2eb0902070606k250e7c85nd00f508acf315386@mail.gmail.com> (raw)
In-Reply-To: <8A4E42EC-54D4-449D-BAB5-C05F6DD97090@gmail.com>
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
>>
>
>
next prev parent reply other threads:[~2009-02-07 14:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-06 2:26 Nityananda
2009-02-06 12:01 ` Thiago Jung Bauermann
2009-02-06 20:22 ` Nityananda
2009-02-07 14:06 ` Ramana Radhakrishnan [this message]
[not found] ` <56d1e8cc0902070843o7e812b46l1897f8c9afd5b03e@mail.gmail.com>
2009-02-07 17:17 ` Ramana Radhakrishnan
2009-02-13 20:52 ` Nityananda
2009-02-19 5:17 ` Nityananda
2009-02-19 5:29 ` Nityananda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67ea2eb0902070606k250e7c85nd00f508acf315386@mail.gmail.com \
--to=ramana.r@gmail.com \
--cc=bauerman@br.ibm.com \
--cc=gdb@sourceware.org \
--cc=j.nityananda@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox