lkml.org 
[lkml]   [2006]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86_64 system call entry points II
Andi Kleen wrote:

>Martin Bisson <bissonm@discreet.com> writes:
>
>
>>- int $0x80/64 bits: All system calls return -1 (EINTR). Is there
>>something wrong in the way I call it:
>>pid_t getpid64()
>>{
>> pid_t resultvar;
>>
>> asm volatile (
>> "int $0x80\n\t"
>> : "=a" (resultvar) : "0" (__NR_getpid)
>> : "memory");
>>
>> return resultvar;
>>}
>>
>>
>
>I tested it now. Since it ends up as a 32bit syscall you're not
>actually calling 64bit getpid() - but 32bit mkdir(). That is because 32bit and 64bit
>have different syscall numbers. For me it returns -14, which is EFAULT.
>Expected for a random argument to mkdir()
>
>
It makes a lot of sense...

I think the bottom line for me is simply that I cannot enter system
calls any way I want with any kernel, among other things because the
kernel expects that we got into the system call using vsyscall stuff and
that the correct way to return to user space is also found in the
vsyscall page.

Thanks for your input.

Mart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-06-06 15:31    [from the cache]
©2003-2011 Jasper Spaans