Re: continuing egcs-1.1 problems

[Gary Thomas <gdt at linuxppc dot org>]

On 11-Nov-98 bacon@aerodyne.com wrote:
> David,
> 
> I'm convinced that the source of our problems is a defective library
> which should be recompiled with a correct compiler.  I'm sorry that I've
> made such a fuss about all of this, but I wanted to get the root problem
> sorted out and fixed.  I my linux machine every day at work, and I need
> the compilers and libraries to function correctly--but most of all to
> function together.  
> 
> I believe we now have a good understanding of where the problem is and
> what needs to be done to correct the situation.  I'm sorry that I've put
> you all to so much trouble, but it was the only way to settle the issue
> and get it corrected.
> 
> Now we need to recompile the library with a correct egcs and verify that
> this will indeed solve our problems.
> 

Note that these comments apply only to EGCS running on Linux/PPC.  I believe
that EGCS works correctly [wrt the topics under discussion here] on other
systems.

I spent all day yesterday looking at this and think I have a handle on it.
Also, I think that there are many items here that need to be addressed
and the final solution is not easily obtained.
  0. Linux/PPC uses SYSV4 ABI, not EABI, so 16 byte alignment is required.
  1. I had an incorrect impression of how the trampoline code was using
     the stack.  [perhaps based on a very early implementation].  I am
     convinced that the trampoline lives as an object in the stack frame
     and that calling "__trampoline_setup" does not change the stack
     pointer (this was my error).  Thus the stack remains properly aligned
     even though the trampoline object may not be 16 byte aligned.
  2. I have verified that the current EGCS compiler does manage the stack
     and trampolines properly without requiring any patches.

However, all of that said, it will be difficult to use EGCS without the 
48 byte trampoline patch in the immediate future.  This is because virtually
every program already built has the [buggy] previously patched 'libgcc'
linked into it.  Changing the compiler now will cause newly compiled 
programs to fail with existing shared libraries and changing the libraries
will cause existing programs to fail.  This is sad indeed because it means
that we're stuck with the [slightly] incorrect code until a completely
clean slate can be used.  The opportunity for this is near;  there will be
a switch to GLIBC 2.1 when it is ready, hopefully soon.  At this point,
all programs and libraries need to be rebuilt anyway since this will involve
a binary imcompatible change.  Thus, the correct compiler behaviour can
be introduced along with GLIBC-2.1.

In the meantime, Linux/PPC users can use EGCS-1.1.1 with this single
change (trampolines of 48 bytes instead of 40).
------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------