Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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
>>
>
>


  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