continuing egcs-1.1 problems

[David Edelsohn]

	From tramp.asm:

__trampoline_size = .-__trampoline_initial

	__trampoline_initial has 10 instructions or .long data areas
between the start and the above assignment, at 4 bytes per instruction and
.long, the total size is 40 bytes.  (For 64-bits the two .long data areas
would be 8 bytes or 48 bytes total.)

r4 = length of trampoline area needed argument to __trampoline_setup call.

        li      r8,__trampoline_size
        cmpw    cr1,r8,r4
...
        blt     cr1,.Labort

r8 is the fixed template size, so this is testing whether the template was
assembled with .long directive having the correct meaning to allow at
least enough space for the two addresses as expected by the compiler
constructing a trampoline call on the stack.  If the template does not
allow enough space for the compiler, this aborts.  The test seems to have
the correct sense and SHOULD NOT be reversed.

	In the failing scenario the compiler requests a trampoline size of
r4 = 48.  The compiler is requesting too much space for some reason.  GCC
and EGCS do not normally request 48 bytes, so this is some non-standard
variant or build of the compiler.

	I suspect that someone built GCC with the
rs6000.c:rs6000_trampoline_size() function changed so that it always
returns 48 in an attempt to keep the stack aligned (not due to accidental
enabling of 64-bit mode within GCC).  However, this only covered up the
symtom instead of fixing the real problem.  This change affects the
self-check in the trampoline template, but the person writing the original
patch did not understand that.

	Now the trampoline test fails and people are patching the
trampoline code to cover up the broken trampoline size code to cover up a
possible stack alignment bug.  Nothing is wrong with EGCS with respect to
the trampoline code.  glibc in LinuxPPC and MkLinux was built with a
half-patched, older version of EGCS that expected an incorrectly-sized
trampoline.  If any of the regular EGCS releases are specifying a
trampoline size of 48 bytes, that is a bug and we need to track down why
it is requesting an oversized area.

	*NO* patches to work around this trampoline mess (neither the
tramp.asm compare sense nor increasing the trampoline size from 40 to 48
bytes) will be applied to egcs-1.1 or any other version as this was not a
bug in any official GCC or EGCS distribution.  If there still is a stack
alignment bug, we need to track that down and fix the code in GCC to
maintain alignment.

David