Re: A serious -fpic and -fomit-frame-pointer bug in egcs 1.0.3/1.1

[Jeffrey A Law <law at cygnus dot com>]

  In message <m0ym0dL-00026AC@ocean.lucon.org>you write:
  > Hi,
  > 
  > There is a serious -fpic and -fomit-frame-pointer bug in egcs 1.0.3/1.1
  > on x86. Basically, they are not compatible with each other.
  > 
  > The problem is in eliminate_regs called by reload. In egcs 1.0.3,
  > eliminate_regs is called by reload around line 979. At the time
  > when you eliminate the frame pointer register with a stack register,
  > you don't know if PIC will do anything with the stack. Unfortunately,
  > on x86, the function prologue is expanded
  > 
  >         subl $16,%esp
  >         pushl %ebx
  >         call .L23
  > .L23:
  >         popl %ebx
  >         addl $_GLOBAL_OFFSET_TABLE_+[.-.L23],%ebx
  > 
  > But eliminate_regs knows nothing about
  > 
  >         pushl %ebx
  >         call .L23
  > .L23:
  >         popl %ebx
  >         addl $_GLOBAL_OFFSET_TABLE_+[.-.L23],%ebx
  >
  > 
  > It doesn't know esp is changed in prologue. As the result, the stack
  > is messed up. I am enclosing a testcase for it.
I do not follow.  It looks to me like the point of this sequence is
to get an offset from the current PC into %ebx and that it should not
care about other changes to the stack pointer in the prologue.

Why does 

	call target
target
	pop returnaddr into %ebx
	add <got magic constant>,%ebx

Care about other stack adjustments that might happen before it?  It
merely must make sure to deallocate any stack the sequence itself
allocates (which it does by popping the return address off the stack
into %ebx).

Without more information I'd say you're looking at the wrong problem.

jeff