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

[David Daney <ddaney@avtrex.com>]

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 ld.so calls mmap which has 6 arguments.
>>
> 
> This patch broke it:
> 
> http://www.linux-mips.org/archives/linux-cvs/2004-11/msg00116.html
> 
> RCS file: /home/cvs/linux/arch/mips/kernel/Attic/scall_o32.S,v
> retrieving revision 1.18.2.13
> retrieving revision 1.18.2.14
> 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    
> 1.18.2.13
> +++ linux/arch/mips/kernel/Attic/scall_o32.S    2004/11/25 09:43:59    
> 1.18.2.14
> @@ -121,9 +121,9 @@ reschedule:
> 
>  trace_a_syscall:
>      SAVE_STATIC
> -    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.