From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21222 invoked by alias); 29 Jul 2011 13:29:27 -0000 Received: (qmail 21213 invoked by uid 22791); 29 Jul 2011 13:29:26 -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-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 29 Jul 2011 13:29:11 +0000 Received: by yxi19 with SMTP id 19so2563375yxi.20 for ; Fri, 29 Jul 2011 06:29:11 -0700 (PDT) Received: by 10.142.242.11 with SMTP id p11mr796266wfh.270.1311946150949; Fri, 29 Jul 2011 06:29:10 -0700 (PDT) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id o3sm1251834wfd.21.2011.07.29.06.29.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 06:29:09 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 4B8AB170C1B3; Fri, 29 Jul 2011 22:59:01 +0930 (CST) Date: Fri, 29 Jul 2011 15:10:00 -0000 From: Alan Modra To: David Edelsohn Cc: Richard Henderson , Michael Meissner , gcc-patches@gcc.gnu.org Subject: Re: [RS6000] asynch exceptions and unwind info Message-ID: <20110729132901.GZ1081@bubble.grove.modra.org> Mail-Followup-To: David Edelsohn , Richard Henderson , Michael Meissner , gcc-patches@gcc.gnu.org References: <20110727053045.GO1081@bubble.grove.modra.org> <20110728072753.GQ1081@bubble.grove.modra.org> <4E31AF2C.2070404@redhat.com> <20110729012748.GR1081@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes 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-07/txt/msg02681.txt.bz2 On Fri, Jul 29, 2011 at 09:16:09AM -0400, David Edelsohn wrote: > Which has the problem? Which are you trying to solve? And how is > your change solving it? Michael's save_toc_in_prologue emit_frame_save writes unwind info for the wrong frame. That r2 save is the current r2. What we need is info about the previous r2, so we can restore when unwinding. I made a similar mistake in frob_update_context in that the value saved by an indirect function call sequence is the r2 for the current function. I also restored from the wrong location. -- Alan Modra Australia Development Lab, IBM