This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: f77 on sco5 fails on GOTOFF references
> > with "-O -fpic", emits assembly code that the native SCO assemblers
> > for neither SCO OpenServer 5 nor Unixware 7/System V Release 5 can
> > grok. Given the common parentage, I suspect this code would fail
> > on systems derived from the other AT&T parentage SVR4 ELF assemblers.
> >
> > The specific line in the assembly that fails is:
> >
> > pushl $.LC0@GOTOFF(%ebx)
>
> You are looking for a contruct that can generate an R_386_GOTOFF
> relocation. I'd thought SVR4 was canonical here -- it surprises
> me that it doesn't work.
It's a bummer, for sure.
> It should be the same thing that
>
> void hello(void)
> {
> printf("Hello, World\n");
> }
>
> generates with -fpic. Failing that, I'll have to defer on how
> to turn off @GOTOFF, though considering the performance hit you'd
> take from always using @GOT, it would be worth convincing whoever
> to fix those assemblers.
OK, that code doesn't quite emit the same thing, but it gave me a much
smaller example to work from.
The SVR5/x86 and OpenServer (and presumably SVR4/x86) assemblers will
accept
pushl .LC0@GOTOFF(%ebx)
but not
pushl $.LC0@GOTOFF(%ebx)
So apparently, these assemblers can't do a push immediate of an assembler-
computed offset.
Isn't this thne functional equivalent of
leal .LC0@GOTOFF(%ebx),%eax
pushl %eax
Oh, I guess this approach clobbers %eax.
It strikes me as odd that in years of GCC support on AT&T-derived
ELF assemblers we've never seen this failure before this Fortran case.
Is this just some sort of thing that the Fortan front-end does that
gcc/g++ front-ends wouldn't do?
I'll report this to SCO in hopes they can fix the SVR5 assembler, but
I think we'll have this problem on many non-GAS x86 ELF targets.
--
Robert Lipe http://www.dgii.com/people/robertl robertl@dgii.com