From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32045 invoked by alias); 13 Feb 2011 09:57:36 -0000 Received: (qmail 32025 invoked by uid 22791); 13 Feb 2011 09:57:35 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wy0-f169.google.com (HELO mail-wy0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 13 Feb 2011 09:57:31 +0000 Received: by wyj26 with SMTP id 26so3963996wyj.0 for ; Sun, 13 Feb 2011 01:57:29 -0800 (PST) Received: by 10.216.143.17 with SMTP id k17mr2161876wej.74.1297591048138; Sun, 13 Feb 2011 01:57:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.243.3 with HTTP; Sun, 13 Feb 2011 01:57:08 -0800 (PST) In-Reply-To: References: From: Anitha Boyapati Date: Sun, 13 Feb 2011 09:57:00 -0000 Message-ID: Subject: Re: Testing Call frame information in .debug_frame section To: =?ISO-8859-1?Q?Petr_Hluz=EDn?= Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2011-02/txt/msg00064.txt.bz2 Hello Petr, On 13 February 2011 08:04, Petr Hluz=EDn wrote: > > > GDB does not use CFI on Atmel AVR, see avr-tdep.c. There is only one > call to frame_unwind_append_unwinder(). Yes. I have looked into the code and it looked like the support is not present. But my understanding is still incomplete. frame-unwind.h/c files are what I have been looking through. Even if it is supported in other targets like ARM perhaps, how do we use that? Which of the gdb commands' processing involves frame unwinding following dwarf2/3/4...? > > I am glad to hear that GCC can somehow emit CFI data. What is the > state of the implementation? It has macros which is defined can fill .debug_frame with CIE and FDE information. The implementation from target side is very minimal. * The prologue instructions that modify frame/stack pointer have to be marked with RTX_FRAME_RELATED_P(). * The hook INCOMING_RETURN_ADDR_RTX should know how to access return address on stack. The return address can be stored in memory or in some register. * Likewise, hook INCOMING_FRAME_SP_OFFSET should specify the stack pointer offset from its previous frame but before prologue of the current function. The macros are documented in stack layout and calling conventions of gcc internals. Emitting CFI is optional in GCC. I used DWARF2 standard and the output seemed to comply it. (For now I am manually verifying the dump of debug_frame section) > I tried to use CFI statements in GAS (binutils), but it cannot parse > them and provides misleading diagnostics. (I even submitted a patch > for that but never received any response.) Sounds interesting. Can you provide the link? > > I tried to improve GDB's ability to scan prologues a year ago, however > I ran out of enthusiasm. (The better scanner would allow stack > reconstruction even without .debug_frame/CFI info.) > How does GDB currently use information from .debug_frame section? From the chat rooms I came to know that current GDB can limp along without CFI information. It tries to scan the prologues and epilogues and build frame information is what I came to know. Although I did not analyze how. > I think I know where and how to hook the new CFI-based unwinder. > However I am not familiar with .debug_frame unwinding in GDB. > I am interested in writing the unwinder. I will need an example ELF > with trivial code run-able in simulator and lots of faith/enthusiasm. > (Assuming the compiler implements this spec: > http://dwarfstd.org/doc/DWARF4.pdf, or dwarf-2.0.0.pdf) > :-) Anitha > -- > Petr Hluzin