On Jan 29, 2013, at 3:59 PM, Nilay wrote:
> 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?
I compile executables to run in SE mode via:
gcc -static hello.c -o hello
How do I compile a binary that has vsyscall offsets that match what's in the
repository?
Mike
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
