public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: David Edelsohn <dje@watson.ibm.com>
To: amodra@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: other/7114: ICE building strcoll.op from glibc-2.2.5
Date: Wed, 17 Jul 2002 13:36:00 -0000	[thread overview]
Message-ID: <20020717203600.17326.qmail@sources.redhat.com> (raw)

The following reply was made to PR other/7114; it has been noted by GNATS.

From: David Edelsohn <dje@watson.ibm.com>
To: Geoff Keating <geoffk@redhat.com>
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
 


             reply	other threads:[~2002-07-17 20:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-17 13:36 David Edelsohn [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-07-17 12:16 Geoff Keating
2002-07-17 12:06 Geoff Keating
2002-07-17 10:46 David Edelsohn
2002-07-17  8:46 David Edelsohn
2002-07-17  2:06 Alan Modra
2002-07-17  0:16 Geoff Keating
2002-07-16 21:16 Alan Modra
2002-07-16 18:56 Alan Modra
2002-07-16 10:56 Geoff Keating
2002-07-16 10:46 Geoff Keating
2002-07-15 22:16 Alan Modra
2002-07-15 21:36 Richard Henderson
2002-07-15 18:46 Alan Modra
2002-07-15 16:56 Alan Modra
2002-07-15 12:46 Geoff Keating
2002-07-15  2:36 Alan Modra
2002-06-25  2:16 d.mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020717203600.17326.qmail@sources.redhat.com \
    --to=dje@watson.ibm.com \
    --cc=amodra@gcc.gnu.org \
    --cc=gcc-prs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).