Hi all,
I tried a simple program for testing clone system call on gem5 (SE mode,
X86). Eventhough clone is implemented in the list of system calls, via
cloneFunc<X86Linux64>; but it works like it's not implemented!
As I checked clone system call always returns in the if clause at
src/sim/syscall_emul.hh:1519 :
if (!(ctc = p->findFreeContext())) {
DPRINTF_SYSCALL(Verbose, "clone: no spare thread context in system"
"[cpu %d, thread %d]", tc->cpuId(), tc->threadId());
return -EAGAIN;
}
Obviously, the reason it returns originates from "ctc =
p->findFreeContext()", in which "findFreeContext()" returns nullptr, but I
cant' figure out why it happens.
I appreciate if any one shares their insight in this regard.
Bests,
MB
On Mon, Mar 11, 2019 at 3:39 PM Potter, Brandon <[email protected]>
wrote:
> Hi Maryam,
>
> The code that you are looking at is going to change soon. There is a
> changeset on the google reviewboard which will add some fidelity to the
> tracing of mmap/munmaps from the perspective of SE mode (
> https://gem5-review.googlesource.com/c/public/gem5/+/12307). Feel free to
> review it if it's interesting to you.
>
> 1) I don't understand what you are asking.
> 2) The new patch has an implementation.
> 3) We could probably add an implementation that flushes file-backed mmaps
> to the host file. I have never run into a situation where this was needed
> in an application that was being simulated (so it doesn't have an
> implementation).
> 4) It turns out that fork is not used in Linux to create a new process. It
> uses the clone system call instead. (You can verify this by using the Linux
> strace command with your application. You should only see a clone call.)
> You should take a look at the clone implementation.
>
> Regards,
> Brandon
>
> -----Original Message-----
> From: gem5-dev <[email protected]> On Behalf Of Maryam Babaie
> Sent: Friday, March 8, 2019 4:06 PM
> To: [email protected]
> Subject: [gem5-dev] Syscall_Emulation for Shared Memory
>
> Hi all,
> I have some questions regarding the system calls available in SE mode on
> gem5 for X86. I appreciate if any one shares their insight about them:
>
> 1. For the mmap syscall, the function "mmapImpl" has been implemented.
> Up-to which extend this function will work properly for mmap syscall?
>
> 2. For munmap syscall, they have put the munmapFunc, but the body of the
> corresponding function is actually empty. So, does this mean it is actually
> not supported on gem5?
>
> 3. msync syscall is flagged as unimplementedFunc. So, does this mean that
> mmap will still work but the writes will not be reflected persistently in
> the region?
>
> 4. Since the fork syscall is also flagged as unimplementedFunc , how is
> the concept of Copy on Write (generally shared pages) able to be simulated
> and handled in gem5?
>
> Regards
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
