f77 on sco5 fails on GOTOFF references

Robert Lipe robertl@dgii.com
Tue Dec 30 08:53:00 GMT 1997

> > 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 
	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

More information about the Gcc mailing list