From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28315 invoked by alias); 18 Feb 2002 17:35:23 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 28251 invoked from network); 18 Feb 2002 17:35:19 -0000 Received: from unknown (HELO dublin.ACT-Europe.FR) (212.157.227.154) by sources.redhat.com with SMTP; 18 Feb 2002 17:35:19 -0000 Received: from berlin.ACT-Europe.FR (berlin.act-europe.fr [212.157.227.169]) by dublin.ACT-Europe.FR (Postfix) with ESMTP id 4C029229E46; Mon, 18 Feb 2002 18:35:15 +0100 (MET) Received: by berlin.ACT-Europe.FR (Postfix, from userid 546) id DF39790E; Mon, 18 Feb 2002 18:35:14 +0100 (CET) To: "John David Anglin" Cc: law@redhat.com, gcc-patches@gcc.gnu.org Subject: Re: Don't use lib2funcs.asm on PA References: <200202181612.g1IGChTK011397@hiauly1.hia.nrc.ca> From: Olivier Hainque Date: Mon, 18 Feb 2002 10:23:00 -0000 In-Reply-To: <200202181612.g1IGChTK011397@hiauly1.hia.nrc.ca> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-02/txt/msg01207.txt.bz2 "John David Anglin" writes: > Thanks for the input. The stack adjust was one thing that was missing. A pleasure :) Nice to hear to input has been useful. > Last night, I arrived at a set of modifications that allow the > "stdexceptions" test in libstdc++ to PASS when linked statically. Great ! > It still doesn't work when linked with a shared libstdc++. There were also > more issues with the frame note code and saving and restoring the eh data > registers. > > I believe that we need an eh_return pattern and use an interspace jump > to return from shared code. I also need to figure out if an eh_return > can return a value. If it can then the data registers need to be revised. > Now on the PA, external calls usually go via a stub. One of the functions > of the stub is to message the outgoing arguments and the return value > so that the caller and callee agree on their location. There could be > a problem with return values because I suspect we bypass the stub on > an eh_return. This is indeed not straightforward and is actually what still needs further work in our setup. > I am going to try to looked at the shared return today. OK. Thanks a lot :) > I enclosed my latest work. Comments appreciated. I have not been able to read it in very detail yet and will do this shortly. Something seems surprising at first sight, though : > @@ -3525,6 +3639,14 @@ hppa_expand_epilogue () > } > else if (actual_fsize != 0) > set_reg_plus_d (STACK_POINTER_REGNUM, STACK_POINTER_REGNUM, - actual_fsize); > + > + if (DO_FRAME_NOTES && current_function_calls_eh_return) > + { > + rtx sa = EH_RETURN_STACKADJ_RTX; > + emit_insn (Pmode == SImode > + ? gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx, sa) > + : gen_adddi3 (stack_pointer_rtx, stack_pointer_rtx, sa)); > + } > > /* If we haven't restored %r2 yet (no frame pointer, and a stack > frame greater than 8k), do so now. */ Isn't this doing the wrong thing in case a function calling __builtin_eh_return returns through a regular return path (as _Unwind_RaiseException might do) ? Avoiding that was the first purpose of introducing an eh_return pattern, but I may well be missing something. Thanks for your feedback, Kind Regards, Olivier