[PATCH] Possible patch to solve PPC multiple mflr issue

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Possible patch to solve PPC multiple mflr issue

Fred Fish-2
For the source code fragment:

    void *
    kzalloc (size_t size)
    {
        void *block;
   
        block = alloc_inline(&kernel_heap, size, "kzalloc");
        if (block)
            (void)memset(block, 0, size);
   
        return(block);
    }

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)

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.

-Fred



diff.out (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Possible patch to solve PPC multiple mflr issue

Daniel Jacobowitz-2
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