This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Possible patch to solve PPC multiple mflr issue
- From: Daniel Jacobowitz <drow at false dot org>
- To: gdb-patches at sourceware dot org
- Date: Mon, 29 Jan 2007 11:25:01 -0500
- Subject: Re: [PATCH] Possible patch to solve PPC multiple mflr issue
- References: <200701271113.04184.fnf@specifix.com>
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