On Tue, January 29, 2013 12:50 pm, Michael Levenhagen wrote:
>
> On Jan 29, 2013, at 11:38 AM, Nilay wrote:
>
>> On Tue, January 29, 2013 11:25 am, Michael Levenhagen wrote:
>>> I think I've found a couple of bugs.
>>>
>>> Mike
>>>
>>> diff -r f9e76b1eb79a src/arch/x86/linux/syscalls.cc
>>> --- a/src/arch/x86/linux/syscalls.cc Tue Jan 22 00:13:28 2013 -0600
>>> +++ b/src/arch/x86/linux/syscalls.cc Tue Jan 29 10:22:31 2013 -0700
>>> @@ -309,7 +309,7 @@
>>> /* 93 */ SyscallDesc("fchown", unimplementedFunc),
>>> /* 94 */ SyscallDesc("lchown", unimplementedFunc),
>>> /* 95 */ SyscallDesc("umask", unimplementedFunc),
>>> - /* 96 */ SyscallDesc("gettimeofday", unimplementedFunc),
>>> + /* 96 */ SyscallDesc("gettimeofday",
>>> gettimeofdayFunc<X86Linux64>),
>>> /* 97 */ SyscallDesc("getrlimit", getrlimitFunc<X86Linux64>),
>>> /* 98 */ SyscallDesc("getrusage", getrusageFunc<X86Linux64>),
>>> /* 99 */ SyscallDesc("sysinfo", sysinfoFunc<X86Linux64>),
>>> @@ -323,7 +323,7 @@
>>> /* 107 */ SyscallDesc("geteuid", geteuidFunc),
>>> /* 108 */ SyscallDesc("getegid", getegidFunc),
>>> /* 109 */ SyscallDesc("setpgid", unimplementedFunc),
>>> - /* 110 */ SyscallDesc("getppid", unimplementedFunc),
>>> + /* 110 */ SyscallDesc("getppid", getppidFunc),
>>> /* 111 */ SyscallDesc("getpgrp", unimplementedFunc),
>>> /* 112 */ SyscallDesc("setsid", unimplementedFunc),
>>> /* 113 */ SyscallDesc("setreuid", unimplementedFunc),
>>> diff -r f9e76b1eb79a src/arch/x86/process.cc
>>> --- a/src/arch/x86/process.cc Tue Jan 22 00:13:28 2013 -0600
>>> +++ b/src/arch/x86/process.cc Tue Jan 29 10:22:31 2013 -0700
>>> @@ -98,7 +98,7 @@
>>> vsyscallPage.base = 0xffffffffff600000ULL;
>>> vsyscallPage.size = VMPageSize;
>>> vsyscallPage.vtimeOffset = 0x400;
>>> - vsyscallPage.vgettimeofdayOffset = 0x410;
>>> + vsyscallPage.vgettimeofdayOffset = 0x000;
>>>
>>> // Set up stack. On X86_64 Linux, stack goes from the top of memory
>>> // downward, less the hole for the kernel address space plus one
>>> page
>>>
>>>
>>
>> The first two changes seem fine. Can you elaborate on the change to
>> process.cc? What was the problem that you faced and how does this change
>> solves it?
>>
>> --
>> Nilay
>>
>>
>
> A test program which calls gettimeofday() incorrectly ends up in the time
> system call. I disassembled the program and looked at the offset used for
> the virtual system call for both time() and gettimeofday().
>
> gettimeofday() uses an offset of 0x0
>
> 000000000040cf30 <__gettimeofday>:
> 40cf30: 48 83 ec 08 sub $0x8,%rsp
> 40cf34: 48 c7 c0 00 00 60 ff mov $0xffffffffff600000,%rax
> 40cf3b: ff d0 callq *%rax
>
> time() uses an offset of 0x400
>
> 000000000042cd90 <time>:
> 42cd90: 48 83 ec 08 sub $0x8,%rsp
> 42cd94: 48 c7 c0 00 04 60 ff mov $0xffffffffff600400,%rax
> 42cd9b: ff d0 callq *%rax
> 42cd9d: 48 83 c4 08 add $0x8,%rsp
>
>
>
This seems like a glibc/linux issue. Do you think some document might
exist that specifies what the offset should be?
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
