strace: Shows wrong system call

[Denys Vlasenko]

On 02/22/2012 01:57 AM, Dmitry V. Levin wrote:
> On Wed, Jan 09, 2008 at 12:12:20AM +0200, Petri Latvala wrote:
>> Package: strace
>> Version: 4.5.14-2
>> Severity: normal
>
> This comes from quite an old Debian bug report
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=459820
> which seems to be actual.
>
>> -- BEGIN TESTCASE PROGRAM --
>>
>> #include<stdio.h>
>> #include<unistd.h>
>>
>> int main ()
>> {
>>   printf("--------------------\n");
>>   __asm__("movl $2, %eax; int $0x80");
>>   printf("[i am %d]\n", getpid());
>>   return 0;
>> }
>>
>> -- END TESTCASE PROGRAM --
>>
>> The testcase code executes fork() by calling it directly. That is,
>> putting 2 (SYS_fork on i386) into eax and doing int 0x80. Let's see how
>> this runs on amd64:
>>
>> --------------------
>> [i am 10869]
>> [i am 10868]
>>
>> Yep, forks. Now let's see what strace tells about it:
>>
>> <snip>
>> write(1, "--------------------\n", 21--------------------
>> )  = 21
>> open(umovestr: Input/output error
>> 0x1, O_WRONLY|0x14[i am 10873]
>> )                = 10873
>> --- SIGCHLD (Child exited) @ 0 (0) ---
>> getpid()                                = 10872
>> write(1, "[i am 10872]\n", 13[i am 10872]
>> )          = 13
>> exit_group(13)                          = ?
>> Process 10872 detached
>>
>>
>> The heading line is printed, then there's an open() printed instead of a
>> fork, yet it did fork.
>>
>> Possible cause: 2 is SYS_fork on i386, and this int 0x80 is i386 way of
>> syscalling. amd64 way is SYSCALL orsomethingicantremember, and 2 is
>> SYS_open on amd64. I don't know whether strace is confused, or whether
>> ptrace() gives out something silly.
>
> There is a commented out code in get_scno() that implements another method
> of personality detection.  Could somebody more familiar with this subject
> have a look?

There was a huge thread on lkml about it, subject
"Compat 32-bit syscall entry from 64-bit task!?"

In short, peeking at text is considered racy -> unreliable.
Linus wanted to add a few magic bits into eflags,
but H. Peter Anvin doesn't like it and prefers a new regset
to be created for this purpose.

-- 
vda