Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Nityananda <j.nityananda@gmail.com>
To: Ramana Radhakrishnan <ramana.r@gmail.com>
Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>,  gdb@sourceware.org
Subject: Re: Help needed with browsing GDB code
Date: Thu, 19 Feb 2009 05:29:00 -0000	[thread overview]
Message-ID: <FBA10FB8-DED6-4367-B79C-C159C04CD265@gmail.com> (raw)
In-Reply-To: <122179EB-05F1-440D-B0C7-86272338854D@gmail.com>

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


      reply	other threads:[~2009-02-19  5:29 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
     [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 [this message]

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=FBA10FB8-DED6-4367-B79C-C159C04CD265@gmail.com \
    --to=j.nityananda@gmail.com \
    --cc=bauerman@br.ibm.com \
    --cc=gdb@sourceware.org \
    --cc=ramana.r@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