This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: continuing egcs-1.1 problems
- To: law at cygnus dot com
- Subject: Re: continuing egcs-1.1 problems
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Wed, 11 Nov 1998 11:54:20 +0100
- Cc: bacon at mediaone dot net, Elgin Lee <ehl at funghi dot com>, David Edelsohn <dje at watson dot ibm dot com>, Fred Bacon <bacon at aerodyne dot com>, Amal Phadke <phadke at kewalo dot eng dot hawaii dot edu>, egcs at cygnus dot com
- References: <Your message of Tue, 10 Nov 1998 18:55:01 MST. <36488C05.C15F8FA1@mediaone.net>
At 01:57 11.11.98 , Jeffrey A Law wrote:
>
> In message <36488C05.C15F8FA1@mediaone.net>you write:
> > > SECOND PATCH (trampoline size tweaking)
> > > =======================================
> > >
> > > I don't have an opinion on this, as I don't know the SVR4 ABI for PPC.
> > > (Is it online somewhere?)
> > >
> > > As it turns out, I never applied to second patch to my egcs 1.1b
> > > build-- only the first one. That seemed to work fine on some small
> > > test programs that invoked the glibc functions that used nested
> > > functions, but I haven't tried it on anything substantial.
> > >
> >
> > When I got home this evening, I dug out my copy of the SysV ABI PowerPC
> > Processor Supplement (July 25, 1994). According to this document, page
> > 3-15:
> >
> > "The following requirements apply to the stack frame:
> > * The stack pointer shall maintain a 16-byte alignment.
> > * The stack pointer shall point to the first word..."
> >
> > Well, the rest is immaterial. So a 40 byte stack frame would be
> > incorrect, but if another portion of egcs is rounding the stack frame
> > size to the next largest 16-byte multiple, then I see no problem with
> > omitting the second patch. But only if the proper alignment is being
> > maintained elsewhere.
>sysv4.h:
>
>/* Alignment in bits of the stack boundary. Note, in order to allow building
> one set of libraries with -mno-eabi instead of eabi libraries and non-eabi
> versions, just use 64 as the stack boundary. */
>#undef STACK_BOUNDARY
>#define STACK_BOUNDARY 64
>
>/* Real stack boundary as mandated by the appropriate ABI */
>#define ABI_STACK_BOUNDARY ((TARGET_EABI) ? 64 : 128)
>
>
>The code to generate the prologue for the ppc is supposed to be rounding the
>stack to ABI_STACK_BOUNDARY. You should verify that it is working properly.
You just might have stumbled over the root of the problems, I seem to
remember that egcs defaults to "-mcall-sysv -meabi" on Linux? That would
explain the 8-Byte alignement, wouldn't it?
Fred, can you run a test with explicitly specifying -mcall-linux?
Franz.