From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28072 invoked by alias); 17 Feb 2011 16:05:05 -0000 Received: (qmail 28052 invoked by uid 22791); 17 Feb 2011 16:05:03 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Feb 2011 16:05:00 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p1HG4ZAt004457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Feb 2011 11:04:35 -0500 Received: from anchor.twiddle.home (ovpn-113-48.phx2.redhat.com [10.3.113.48]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p1HG4Y4F019603; Thu, 17 Feb 2011 11:04:35 -0500 Message-ID: <4D5D4712.8000405@redhat.com> Date: Thu, 17 Feb 2011 16:05:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Anitha Boyapati CC: GCC Patches , =?ISO-8859-1?Q?Petr_Hluz=EDn?= , binutils@sourceware.org, gdb@sourceware.org, chertykov@gmail.com, aesok@post.ru, eric.weddington@atmel.com Subject: Re: [avr] gas support for cfi info References: <4D5ABAB2.2000405@redhat.com> <4D5ACDF2.20904@redhat.com> <4D5C104D.7050707@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00218.txt.bz2 On 02/17/2011 07:35 AM, Anitha Boyapati wrote: > Can you please explain the logic behind the following lines in gcc patch: > > > - offset = -cfa_store.offset; > + if (GET_CODE (XEXP (dest, 0)) == POST_DEC) > + offset += -cfa_store.offset; > + else > + offset = -cfa_store.offset; This is differentiating between pre-dec and post-dec. pre-dec post-dec before stuff stuff stuff <-sp trash <-sp trash after stuff stuff stuff value value <-sp trash <-sp We've just decremented cfa_store.offset by the size of the pushed value, and we're computing the offset of VALUE from the CFA. For pre-decrement, the value is stored at the CFA offset (the else); for post-decrement, the value is stored just above the CFA offset. I admit the logic is confusing here, because we're storing some quantities as positive offsets, and some quantities as negative offsets, and we're also using the same variable for two different things over two sections of code. Perhaps it would have been less obtuse if I had written offset = -(cfa_store.offset - offset); > However I have one simple question with regarding the output: The CFI > instructions for registers have changed only after the prologue. (For > convenience I have attached disassembly too). As far as I understand, > DWARF2 spec emits CFI instructions immediately. (Appendix 5 of DWARF2 > specification) GCC is attempting to minimize the number of advance opcodes by grouping the DW_CFA_offset opcodes. We can delay emission of such until the registers in question are actually clobbered. In this case this delay tactic failed because of the push -- we cannot delay changes to the CFA. > 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. We should fix this separately. r~