[Top] [All Lists]

Re: Strace doesn't work on linux-2.4.28 and later

To: David Daney <>
Subject: Re: Strace doesn't work on linux-2.4.28 and later
From: David Daney <>
Date: Mon, 07 Feb 2005 11:39:12 -0800
Cc: andreev <>, Ralf Baechle <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
David Daney wrote:
andreev wrote:

Hi, list.

We are using the latest kernel from mips-linux CVS and there is a problem with ptrace.

When syscall with 5 or more arguments are traced, the fifth argument of the syscall is overwritten by tracing code. This error causes problems with strace. For example, you can't trace dynamically linked
applications, because calls mmap which has 6 arguments.

This patch broke it:

RCS file: /home/cvs/linux/arch/mips/kernel/Attic/scall_o32.S,v
retrieving revision
retrieving revision
diff -u -p -r1.18.2.13 -r1.18.2.14
--- linux/arch/mips/kernel/Attic/scall_o32.S 2004/04/26 15:06:02 +++ linux/arch/mips/kernel/Attic/scall_o32.S 2004/11/25 09:43:59
@@ -121,9 +121,9 @@ reschedule:

-    sw    t2, PT_R1(sp)
+    sw    t2, PT_SCRATCH0(sp)
     jal    syscall_trace
-    lw    t2, PT_R1(sp)
+    lw    t2, PT_SCRATCH0(sp)

     lw    a0, PT_R4(sp)        # Restore argument registers
     lw    a1, PT_R5(sp)

PT_SCRATCH0(sp) = 16(sp) which is where arg5 is stored. This overwrites it.

In arch/mips/tools/offset.c we have:

    offset("#define PT_SCRATCH0 ", struct pt_regs, pad0[4]);
    offset("#define PT_SCRATCH1 ", struct pt_regs, pad0[5]);

I am thinking of testing a patch where I change them to:

    offset("#define PT_SCRATCH0 ", struct pt_regs, pad0[0]);
    offset("#define PT_SCRATCH1 ", struct pt_regs, pad0[1]);

Any needed argument registers are already saved in and restored from the regs array so overwriting the stack area reserved for them should be OK.

I now think that is bogus reasoning as the first four slots can be clobbered by the compiler.

It seems that t2 must be saved somewhere in the regs list. I am not sure what the problem with PT_R1(sp) was, but it seems like a good candidate. Perhaps PT_R26 or PT_R27 (k0, k1) would be a better place to store t2 as I don't think k0 or k1 are ever stored.

David Daney.

<Prev in Thread] Current Thread [Next in Thread>