From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24241 invoked by alias); 7 May 2003 14:54:18 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24191 invoked from network); 7 May 2003 14:54:17 -0000 Received: from unknown (HELO faui11.informatik.uni-erlangen.de) (131.188.31.2) by sources.redhat.com with SMTP; 7 May 2003 14:54:17 -0000 Received: (from weigand@localhost) by faui11.informatik.uni-erlangen.de (8.9.1/8.1.4-FAU) id QAA07836; Wed, 7 May 2003 16:49:13 +0200 (MET DST) From: Ulrich Weigand Message-Id: <200305071449.QAA07836@faui11.informatik.uni-erlangen.de> Subject: Re: GCC 3.3 Prelease broken on s390 To: rth@redhat.com (Richard Henderson) Date: Wed, 07 May 2003 14:54:00 -0000 Cc: weigand@immd1.informatik.uni-erlangen.de (Ulrich Weigand), mark@codesourcery.com, gcc@gcc.gnu.org In-Reply-To: <20030507012508.GD7654@redhat.com> from "Richard Henderson" at May 06, 2003 06:25:08 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00629.txt.bz2 Richard Henderson wrote: > Ah, now I get it. This was the piece I couldn't understand. > And if *this* is the case, it means that it doesn't matter > where you place the CFA relative to the stack frame, just so > long as the stack pointer itself is computed properly. This is what I was thinking, yes. > > * unwind-dw2.c (uw_update_context_1): Only set cfa as sp if > > previous frame didn't save sp. Clear sp for next frame. > > (uw_install_context_1): Honor saved sp from frame. > > If this works, great. Unfortunately, while it fixes most of the problems, it is not a complete solution: http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00418.html http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00419.html The Java test case PR218 is still failing. This is because this test case throws an exception from a signal handler through a *leaf* function that was interrupted by the signal. When unwinding through the leaf function, there is no CFA code to restore the stack pointer, because the *correct* behaviour would have been to reuse the stack pointer from the frame below (the signal return stub frame) unchanged -- the leaf function really did not allocate any stack space. However, this now triggers again the new code that sets the stack pointer to the cfa, incorrect on s390. Would you suggest to check the above patch in anyway to make 3.3 more similar to head (apparently the patch is already in 3.2 ...), and because it fixes at least C++? Or should we go back to a RUNTIME_SP_CFA_OFFSET solution on top of the current 3.3 implementation? What about an alternate target macro that says that this target handles SP by itself via FDE records, and doesn't need any other SP fiddling? This would then allow us to remove the unnecessary EH_RETURN_STACKADJ_RTX handling completely. Maybe this behaviour could actually be triggered by the target leaving EH_RETURN_STACKADJ_RTX undefined? If no other solution works for 3.3, we could always fix it ad-hoc with #ifdef __s390__ ... Bye, Ulrich -- Dr. Ulrich Weigand weigand@informatik.uni-erlangen.de