[PATCH] Possible patch to solve PPC multiple mflr issue

[Daniel Jacobowitz]

On Sat, Jan 27, 2007 at 11:13:04AM -0700, Fred Fish wrote:
> A powerpc-eabi toolchain can produce this code when using the
> option -fstack-limit-register=r2 :
> 
>     kzalloc:
> 	addi 0,2,24
> 	mflr 5
> 	twllt 1,0
> 	stwu 1,-24(1)
> 	mflr 0
> 	stw 29,12(1)
> 	mr 29,3
> 	lis 3,kernel_heap@ha
> 	mr 4,29
> 	la 3,kernel_heap@l(3)
> 	stw 31,20(1)
> 	stw 0,28(1)

Is that is a completely useless mflr, or did you just not show the use?

> Note the first move of the link register to r5.  The skip_prologue
> code in rs6000-tdep.c specifically ignores all but the first mflr, so
> gdb never detects that the link register was saved on the stack.  This
> interferes with gdb's ability to do a proper backtrace.  Older
> versions of gdb (like 6.1) actually work around this by assuming that
> the link register was saved in it's normal offset relative to the
> stack pointer and default to getting it from there.
> 
> Attached is the patch I've tested, and it works, but it still has the
> potential to fail if there are more than two mflr's, or if one of the
> results of a preceding mflr is stored to the stack before the real
> save of the link register.

This is pretty ugly... I wonder how much work it would be to make
powerpc use prologue-value.h?  At that point, we could look through
the results after simulating the program and find the stack location
containing the lr.

-- 
Daniel Jacobowitz
CodeSourcery