From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17355 invoked by alias); 17 Jul 2002 20:36:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 17327 invoked by uid 71); 17 Jul 2002 20:36:00 -0000 Date: Wed, 17 Jul 2002 13:36:00 -0000 Message-ID: <20020717203600.17326.qmail@sources.redhat.com> To: amodra@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: David Edelsohn Subject: Re: other/7114: ICE building strcoll.op from glibc-2.2.5 Reply-To: David Edelsohn X-SW-Source: 2002-07/txt/msg00540.txt.bz2 List-Id: The following reply was made to PR other/7114; it has been noted by GNATS. From: David Edelsohn To: Geoff Keating Cc: amodra@bigpond.net.au, d.mueller@elsoft.ch, gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: other/7114: ICE building strcoll.op from glibc-2.2.5 Date: Wed, 17 Jul 2002 16:28:02 -0400 >>>>> Geoff Keating writes: >> PUSH/POP cannot work on PowerPC. On AIX PUSH/POP were corrupting the >> stack. Geoff> Because they were implemented wrongly? Geoff> Clearly, push/pop can work, because procedures push and pop call Geoff> frames all the time. It's just necessary to do it the right way. We are discussing PUSH/POP in the context of the macros to save and restore individual registers used when generating a profiler call in final.c, so GCC's ability to correctly allocate call frames is irrelevant. The discussion about the PUSH/POP macros in March 1999 provides more background about the problem: the macros were not respecting the ABI-defined location of dynamic allocation on the stack. PUSH/POP ideally should work like alloca and open a hole in the stack frame at the alloca location. The PUSH/POP macros modify the stack pointer without updating the compiler's internal knowledge about the stack layout and assume that the alloca area is adjacent to the top of the stack, so adjusting the stack pointer will not have any bad consequences, e.g., if a function call is invoked. On AIX, things went haywire because the PUSH/POP macros only copied the backchain pointer, not all of the ABI-specified area between the backchain pointer and the alloca area. When GCC called the profiler function, the call frame had random garbage in ABI-specified locations, causing the application to run off the rails when an ABI stack location was accessed in the called function. Copying the backchain *and* CR *and* LR may be sufficient for the AIX case for this particular use. Because SVR4 PowerPC invokes the profiler before the prologue and has a slightly different stack layout, the simplistic definition of PUSH/POP may work correctly. David