From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21501 invoked by alias); 25 Mar 2011 17:35:58 -0000 Received: (qmail 21403 invoked by uid 22791); 25 Mar 2011 17:35:58 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Mar 2011 17:35:54 +0000 Received: (qmail 9735 invoked from network); 25 Mar 2011 17:35:52 -0000 Received: from unknown (HELO ?84.152.188.150?) (bernds@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Mar 2011 17:35:52 -0000 Message-ID: <4D8CD227.5090205@codesourcery.com> Date: Fri, 25 Mar 2011 17:51:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Richard Henderson CC: GCC Patches Subject: Re: [PATCH 3/6] Allow jumps in epilogues References: <4D8A0703.9090306@codesourcery.com> <4D8A089D.7020507@codesourcery.com> <4D8A23E8.4090802@redhat.com> <4D8A245A.20701@codesourcery.com> <4D8A2B86.4080402@redhat.com> In-Reply-To: <4D8A2B86.4080402@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg01778.txt.bz2 On 03/23/2011 06:19 PM, Richard Henderson wrote: > In general, with shrink-wrapping, we can have essentially arbitrary > differences in unwind info between blocks that are sequential. So, while that isn't the case just yet with the current shrink-wrapping patch, it seems I will either have to make dwarf2out fully general, or ensure that basic blocks occur in only a certain order (the prologue must be written out only after all basic blocks that can be executed before or without reaching it). I don't know much about the unwinding code. I'm currently thinking about writing out a cfi_remember_state at the start of the function, restoring that clean state when necessary at the start of a new block and emitting the necessary directives to reach the correct state. What directives should I expect to be required? Can I get by just with cfi_offset and cfi_def_cfa_offset, or will something else be necessary? Bernd