[PATCH] Possible patch to solve PPC multiple mflr issue

Fred Fish fnf@specifix.com
Sat Jan 27 18:13:00 GMT 2007


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff.out
Type: text/x-diff
Size: 3019 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20070127/7170e56b/attachment.bin>


More information about the Gdb-patches mailing list