From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7292 invoked by alias); 22 Feb 2011 16:18:06 -0000 Received: (qmail 7132 invoked by uid 22791); 22 Feb 2011 16:18:03 -0000 X-SWARE-Spam-Status: No, hits=0.3 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-ew0-f41.google.com (HELO mail-ew0-f41.google.com) (209.85.215.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Feb 2011 16:17:55 +0000 Received: by ewy10 with SMTP id 10so1364269ewy.0 for ; Tue, 22 Feb 2011 08:17:52 -0800 (PST) Received: by 10.216.143.17 with SMTP id k17mr3348178wej.74.1298391472107; Tue, 22 Feb 2011 08:17:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.243.3 with HTTP; Tue, 22 Feb 2011 08:17:32 -0800 (PST) In-Reply-To: <4D5D7C86.2080804@redhat.com> References: <4D5ABAB2.2000405@redhat.com> <4D5ACDF2.20904@redhat.com> <4D5C104D.7050707@redhat.com> <4D5D4712.8000405@redhat.com> <4D5D7C86.2080804@redhat.com> From: Anitha Boyapati Date: Tue, 22 Feb 2011 16:18:00 -0000 Message-ID: Subject: Re: [avr] gas support for cfi info To: Richard Henderson , GCC Patches Cc: =?ISO-8859-1?Q?Petr_Hluz=EDn?= , gdb@sourceware.org, chertykov@gmail.com, aesok@post.ru, eric.weddington@atmel.com 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/msg00123.txt.bz2 2011/2/18 Richard Henderson > > On 02/17/2011 08:04 AM, Richard Henderson wrote: > >> The other scenario is - how about functions with signals/interrupts? > >> The compiler will give an ICE compiling a function as below: > >> > >> void my_interrupt_handler() __attribute__ (("interrupt")); > > > > It's a bug in the avr backend; the enable_interrupt insn should not be > > marked as frame-related. =A0We should fix this separately. > > Looking at this closer, it seem that the FRAME_RELATED markers in avr.c > were sprinkled at random without really knowing what is going on. This is quite a clean up! I am yet to reach the changes in expand_epilogue. > =A0There > were 2 places where UNSPEC_VOLATILE insns were marked frame related, > somehow expecting the unwinder to do something magical. > Just to be on same page, these are the 2 places: 1. gen_enable_interrupt() 2. gen_call_prologue_saves() For the latter, can you explain why adding reg notes is required? + add_reg_note (insn, REG_CFA_ADJUST_CFA, + gen_rtx_SET (VOIDmode, + (frame_pointer_needed + ? frame_pointer_rtx : stack_pointer_rtx), + plus_constant (stack_pointer_rtx, + -(size + live_seq)))); + (The comment does say that this is to describe the effect of UNSPEC_VOLATILE, but how reg notes help?) > The following cleans all that up. =A0There are a couple of odd points: > > =A0(1) SREG and RAMPZ cannot be annotated as saved in the frame of an > =A0 =A0 =A0interrupt function without allocating hard register numbers for > =A0 =A0 =A0these registers. =A0Not to be confused with "real" registers, > =A0 =A0 =A0these need a number in the same way that SP_L and SP_H have > =A0 =A0 =A0register numbers. > > =A0 =A0 =A0I've simply ignored unwind info for these for now. > In addition to the above, there are atleast 4 more registers RAMPX, RAMPY, RAMPD and EIND. (Actually the support for these registers is in the form of patches which aren't upstream yet) > =A0(2) At present it's possible to use epilogue_restores without > =A0 =A0 =A0having used prologue_saves. =A0I.e. use epilogue_restores with > =A0 =A0 =A0an inline prologue. =A0The problem being that the inline prolo= gue > =A0 =A0 =A0uses an HImode push of REG_Y (i.e. r29 first), whereas the code > =A0 =A0 =A0in prologue_saves pushes r28 first and epilogue_restores is > =A0 =A0 =A0written to expect that. > Is this is the line being referred to ? if (frame_pointer_needed) { ... /* Push frame pointer. */ insn =3D emit_move_insn (pushword, frame_pointer_rtx); On the whole, when the patch is applied, an ICE is longer generated during the compilation of interrupt and signal functions. I am yet to see the changes due to ARG_POINTER_CFA_OFFSET(FNDECL) definition and the complete unwind info incase of interrupts. Anitha