From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4387 invoked by alias); 13 Feb 2009 20:52:17 -0000 Received: (qmail 4371 invoked by uid 22791); 13 Feb 2009 20:52:16 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from rv-out-0708.google.com (HELO rv-out-0708.google.com) (209.85.198.240) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Feb 2009 20:52:10 +0000 Received: by rv-out-0708.google.com with SMTP id c5so763351rvf.48 for ; Fri, 13 Feb 2009 12:52:08 -0800 (PST) Received: by 10.142.126.6 with SMTP id y6mr1101692wfc.52.1234558328153; Fri, 13 Feb 2009 12:52:08 -0800 (PST) Received: from ?10.0.1.197? (dhcp-004086.ics.uci.edu [128.195.4.86]) by mx.google.com with ESMTPS id 30sm3919963wfg.54.2009.02.13.12.52.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Feb 2009 12:52:06 -0800 (PST) Cc: Thiago Jung Bauermann , gdb@sourceware.org Message-Id: From: Nityananda To: Ramana Radhakrishnan In-Reply-To: <67ea2eb0902070917k67eba8b5j2509945281117616@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Help needed with browsing GDB code Date: Fri, 13 Feb 2009 20:52:00 -0000 References: <249DE25A-9555-4D36-8C59-56EF08F2E34A@gmail.com> <1233921666.14735.108.camel@localhost.localdomain> <8A4E42EC-54D4-449D-BAB5-C05F6DD97090@gmail.com> <67ea2eb0902070606k250e7c85nd00f508acf315386@mail.gmail.com> <56d1e8cc0902070843o7e812b46l1897f8c9afd5b03e@mail.gmail.com> <67ea2eb0902070917k67eba8b5j2509945281117616@mail.gmail.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00111.txt.bz2 Hi Ramana, Thanks for that insightful mail. I however have more questions about how GDB works. I would really=20=20 appreciate it if you could explain how it works along with pointers=20=20 into the code. How are the local variables found when the gcc is used with the fomit-=20 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 > wrote: >> Hi Ramana, >> Thanks a lot for pointing me in the right direction. I will look at=20=20 >> the code >> now.....i was wondering whether the local variables are always at=20=20 >> the same >> offset from the frame address since there are some measures of=20=20 >> security now >> like stack randomization and stack guards along with address space=20=20 >> 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=20=20 >> get to an >> outer frame when there is no information in this current frame=20=20 >> which points >> us to the previous frame? The GDB internals page says that the=20=20 >> previous page >> can be reached from the next younger frame, but using what pointer/=20 >> 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 > > >> wrote: >>> >>> Hi Nityananda, >>> >>> >>> On Sat, Feb 7, 2009 at 1:52 AM, Nityananda=20=20 >>> wrote: >>>> HI Thiago, >>>> Thanks for the information. I am reading the code to deal with=20=20 >>>> the stack >>>> frame information without the debug information. Can you please=20=20 >>>> point me >>>> to >>>> the code with the debug information? You mentioned that it uses=20=20 >>>> DWARF2. >>> >>> Look at gdb/dwarf2-frame.c for DWARF2 frame reading . >>> >>>> So are the local variables always at the same offset of the frame=20=20 >>>> base >>>> address >>>> or there is a possibility of these addresses changing from one=20=20 >>>> process >>>> to >>>> another? >>> >>> Local variables will always be at the same offset from the frame=20=20 >>> 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=F3: >>>>>> >>>>>> I am looking for how >>>>>> GDB obtains the address of stack local variables. I am seeing=20=20 >>>>>> some >>>>>> code related to frame_info but do not know how it actually works. >>>>> >>>>> Well, there are two situations: with debug information=20=20 >>>>> available, and >>>>> without. For the first case it's simple: the DWARF2 format=20=20 >>>>> includes the >>>>> frame base address as part of the unwind information, and=20=20 >>>>> addresses of >>>>> local variables in the debuginfo are relative to that base=20=20 >>>>> address. >>>>> >>>>> When there's no debuginfo available, GDB uses its knowledge of=20=20 >>>>> the OS >>>>> ABI for the given architecture. For example, for ppc64-linux,=20=20 >>>>> the stack >>>>> frame layout is given here: >>>>> >>>>> >>>>> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#S= TACK >>>>> >>>>> 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 >>>>> >>>> >>>> >> >>