pushl computed immediate address on 2.8.1

pushl computed immediate address on 2.8.1

[Robert Lipe]

I was thinking this was a bug in the SCO x86 assembler becuase it worked
under GAS for Linux.   However, after some prodding form the egcs folks 
that really know PIC, I'm wondering if this is actually a construct that 
GAS should produce an error for becuase GCC shouldn't emit it.

The problem is that 

	pushl $.LC0@GOTOFF(%ebx)

seems to assemble just like

	pushl $LC0

so it ends up generating an push of an absolute address once the 
linker gets done with it.

Does this sound right at all?    Should GAS error on this?


Here's a short "hello, world" in PIC to exercise the issue.


Thanx,

RJL

	.file	"test.c"
	.section	.rodata
.LC0:
	.string	"Hello, World\n"

	.text
	.align 4
	.globl main
	.type	 main,@function
main:
	pushl %ebp
	movl %esp,%ebp
	pushl %ebx
	call .L2
.L2:
	popl %ebx
	addl $_GLOBAL_OFFSET_TABLE_+[.-.L2],%ebx

// This is the aproach that works, and is what GCC should emit.
// registers
	leal .LC0@GOTOFF(%ebx),%eax
	pushl %eax
	call printf@PLT

// This what GCC does emit, but seems to be nonsensical.
// assembler.
	pushl $.LC0@GOTOFF(%ebx)
	call printf@PLT

	movl -4(%ebp),%ebx
	movl %ebp,%esp
	popl %ebp
	ret
	.size	 main,.-main

Re: pushl computed immediate address on 2.8.1

[Ian Lance Taylor]

   Date: Fri, 2 Jan 1998 14:40:41 -0600
   From: Robert Lipe <robertl@dgii.com>

   I was thinking this was a bug in the SCO x86 assembler becuase it worked
   under GAS for Linux.   However, after some prodding form the egcs folks 
   that really know PIC, I'm wondering if this is actually a construct that 
   GAS should produce an error for becuase GCC shouldn't emit it.

   The problem is that 

	   pushl $.LC0@GOTOFF(%ebx)

   seems to assemble just like

	   pushl $LC0

   so it ends up generating an push of an absolute address once the 
   linker gets done with it.

This happens because when gas sees the '$', it passes the rest of the
line to the expression parsing code.  The expression parser doesn't
recognize the '@', so it just returns .LC0.  gas then fails to notice
that part of the line wasn't parsed.

   Does this sound right at all?    Should GAS error on this?

It sounds wrong, and I'll change gas to emit an error.

Ian

Re: pushl computed immediate address on 2.8.1

[Robert Lipe]

> 	   pushl $.LC0@GOTOFF(%ebx)
>    seems to assemble just like
> 	   pushl $LC0
> 
> This happens because when gas sees the '$', it passes the rest of the
> line to the expression parsing code.  The expression parser doesn't
> recognize the '@', so it just returns .LC0.  gas then fails to notice
> that part of the line wasn't parsed.

That sounds like a perfectly reasonable explanation.

>    Does this sound right at all?    Should GAS error on this?
> It sounds wrong, and I'll change gas to emit an error.

This exercise wasn't entirely academic.   EGCS (and presumably GCC) 
actually will emit this construct.   So, although I agree it is the 
right thing to do for the assembler to complain about this, be 
prepared that doing so will "break" those tools.   

Of course, they never _really_ worked right, but the output would 
actually give the desired results in some cases.     We'll probably 
hear that GAS "broke" the compiler for a while, but in reality, I 
think this is a healthy thing and will help expose the real problem 
in the x86 part of the compilers.

Thank you, Ian.

RJL

Re: pushl computed immediate address on 2.8.1

[H.J. Lu]

> 
> 
> I was thinking this was a bug in the SCO x86 assembler becuase it worked
> under GAS for Linux.   However, after some prodding form the egcs folks 
> that really know PIC, I'm wondering if this is actually a construct that 
> GAS should produce an error for becuase GCC shouldn't emit it.
> 
> The problem is that 
> 
> 	pushl $.LC0@GOTOFF(%ebx)
> 
> seems to assemble just like
> 
> 	pushl $LC0
> 
> so it ends up generating an push of an absolute address once the 
> linker gets done with it.
> 
> Does this sound right at all?    Should GAS error on this?
> 
> 
> Here's a short "hello, world" in PIC to exercise the issue.
> 
> 
> Thanx,
> 
> RJL
> 
> 	.file	"test.c"
> 	.section	.rodata
> .LC0:
> 	.string	"Hello, World\n"
> 
> 	.text
> 	.align 4
> 	.globl main
> 	.type	 main,@function
> main:
> 	pushl %ebp
> 	movl %esp,%ebp
> 	pushl %ebx
> 	call .L2
> .L2:
> 	popl %ebx
> 	addl $_GLOBAL_OFFSET_TABLE_+[.-.L2],%ebx
> 
> // This is the aproach that works, and is what GCC should emit.
> // registers
> 	leal .LC0@GOTOFF(%ebx),%eax
> 	pushl %eax
> 	call printf@PLT
> 
> // This what GCC does emit, but seems to be nonsensical.
> // assembler.
> 	pushl $.LC0@GOTOFF(%ebx)
> 	call printf@PLT
> 

Which gcc are you using? How did you get gcc to emit that?
I only can get my gcc to generate

leal .LC0@GOTOFF(%ebx),%eax
pushl %eax
call printf@PLT

I tried egcs 971215, egcs 1.0.1 and gcc 2.8.0 971225. They
are all the same.

H.J.

Re: pushl computed immediate address on 2.8.1

[Robert Lipe]

Re: Test case containing cryptic assembler to exercise a GAS problem.

> > // This is the aproach that works, and is what GCC should emit.
> > // registers
> > 	leal .LC0@GOTOFF(%ebx),%eax
> > 	pushl %eax
> > 	call printf@PLT
> > 
> > // This what GCC does emit, but seems to be nonsensical.
> > // assembler.
> > 	pushl $.LC0@GOTOFF(%ebx)
> > 	call printf@PLT
> > 
> 
> Which gcc are you using? How did you get gcc to emit that?

We have to try really hard. :-)

I can see this behaviour specifically on EGCS 1.0.1 under g77
when targeted for i586-pc-sco3.2v5.0.4.  It does not equate 
exactly to the test case that I submitted to the GAS2 list as 
I was trying to show an assembler problem, not the gcc problem.
As an aside, Richard Henderson did take an interest just this
morning in solving the gcc problem.   See the thread at:
	http://www.cygnus.com/ml/egcs/1998-Jan/0208.html
	

Looking at the example I gave more, I implied that this was from 
"hello world" compiled as PIC.    This was wrong.   I apologize.
I grafted the failure from a f77 test case into a C hello world 
and didn't make that clear.   I was focusing on the gas issue on 
this list and the gcc issues in the egcs list.   In trying to 
simplify the gas test case, I obscured the actual case where 
gcc/egcs would emit this.

You can see one real example of this failure by running g77 with -fPIC 
and -O3:

$ g77 -O3 -fPIC /play/egcs/gcc/testsuite/g77.f-torture/execute/short.f -o /tm>
/usr/tmp/cca003D7.s:136:syntax error at (
/usr/tmp/cca003D7.s:151:syntax error at (
/usr/tmp/cca003D7.s:162:syntax error at (
/usr/tmp/cca003D7.s:173:syntax error at (
(robertl) rjlhome:/play/egcs/gcc/testsuite/g77.f-torture/execute
$ g77 --version
egcs-2.90.23 980102 (egcs-1.0.1 release)

The lines it wails about are of the form:
        pushl $.LC4@GOTOFF(%ebx)

The assembler in the case above is not  GAS.  It's the OpenServer 5.0.4
assembler.     GAS should complain about this as well.


Does EGCS 1.0.1 for GNU/Linux for x86 really emit something different,
or did you get tripped up in my obscurity in the test case?  If so, I'm
sorry to have wasted your time.

-- 
Robert Lipe       http://www.dgii.com/people/robertl       robertl@dgii.com

Re: pushl computed immediate address on 2.8.1

[H.J. Lu]

> 
> Looking at the example I gave more, I implied that this was from 
> "hello world" compiled as PIC.    This was wrong.   I apologize.
> I grafted the failure from a f77 test case into a C hello world 
> and didn't make that clear.   I was focusing on the gas issue on 
> this list and the gcc issues in the egcs list.   In trying to 
> simplify the gas test case, I obscured the actual case where 
> gcc/egcs would emit this.
> 

Now, that makes senses.

> You can see one real example of this failure by running g77 with -fPIC 
> and -O3:
> 
> $ g77 -O3 -fPIC /play/egcs/gcc/testsuite/g77.f-torture/execute/short.f -o /tm>
> /usr/tmp/cca003D7.s:136:syntax error at (
> /usr/tmp/cca003D7.s:151:syntax error at (
> /usr/tmp/cca003D7.s:162:syntax error at (
> /usr/tmp/cca003D7.s:173:syntax error at (
> (robertl) rjlhome:/play/egcs/gcc/testsuite/g77.f-torture/execute
> $ g77 --version
> egcs-2.90.23 980102 (egcs-1.0.1 release)
> 
> The lines it wails about are of the form:
>         pushl $.LC4@GOTOFF(%ebx)
> 
> The assembler in the case above is not  GAS.  It's the OpenServer 5.0.4
> assembler.     GAS should complain about this as well.
> 
> 
> Does EGCS 1.0.1 for GNU/Linux for x86 really emit something different,
> or did you get tripped up in my obscurity in the test case?  If so, I'm
> sorry to have wasted your time.

Yes. Thanks for clearing it up. I have so many emails to go through
after coming back from a vacation :-(.


-- 
H.J. Lu (hjl@gnu.org)