Re: continuing egcs-1.1 problems

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Amal Phadke writes:

>> Fred, can you run a test with explicitly specifying -mcall-linux?

Amal> I compiled Fred's test code with patched and unpatched versions of egcs
Amal> 1.1b with -mcall-linux command line option. (The patched version of egcs
Amal> contains both patches.) The test code compiled with unpatched egcs still
Amal> bombs out. Code compiled with patched egcs works fine.

	The problem is that glibc distributed with LinuxPPC and MkLinux
was compiled with the the incorrect trampoline size.  glibc has a call to
create a trampoline and passes the incorrect trampoline size of 48 as an
argument to the trampoline setup procedure.  The application is compiled
with the EGCS with tramp.asm included in libgcc.a using the correct sense
of the trampoline size test.  This always will fail because glibc still
has trampoline size 48 compiled in when it calls the procedure in libgcc.a.

	The only issue with -mcall-linux is whether that fixes the stack
alignment problem that instigated the change in trampoline size.
-mcall-linux will have not change this particular abort because that is a
symtom of previous incorrect GCC patches used when compiling glibc.  Only
recompiling glibc correctly, possibly with -mcall-linux, will fix the
abort. 

	Looking at the PowerPC Linux configuration, I do not see where it
uses eABI, but I am not sure if I am missing something or if this was
changed at some point.  -mcall-linux appears to be the default.  If it is
using SVR4 ABI, then the stack boundary alignment is 16 bytes *NOW*.  It
may not have been that in the past.  I do not know if the less strict
stack alignment was a bug in EGCS or cockpit error by using EGCS in eABI
mode.  If EGCS is not aligning the stack to 16 bytes when it truly is
invoked in SVR4 ABI mode, then that is a bug and we need to fix the code
that maintains alignment, *NOT* change the size of the trampoline.

David