Hi all, Perhaps obvious, but why not run in full-system mode? Clearly there are trade-offs, but ultimately it opens up for more realistic workloads.
Andreas On 21/04/2016, 01:11, "gem5-dev on behalf of Potter, Brandon" <[email protected] on behalf of [email protected]> wrote: >Hello Sooraj, > >This changeset from the Linux git repo looks relevant: > 5590ff0d5528b60153c0b4e7b771472b5a95e297 > >It dates back to 01/18/2006 when Drepper added some system calls to the >Linux source. > > $> git diff 5590ff0d5528b60153c0b4e7b771472b5a95e297^ >5590ff0d5528b60153c0b4e7b771472b5a95e297 > diff --git a/fs/stat.c b/fs/stat.c > index b8a0e51..24211b0 100644 > --- a/fs/stat.c > +++ b/fs/stat.c > > +asmlinkage long sys_newfstatat(int dfd, char __user *filename, > + struct stat __user *statbuf, int >flag) > +{ > + struct kstat stat; > + int error = -EINVAL; > + > + if ((flag & ~AT_SYMLINK_NOFOLLOW) != 0) > + goto out; > + > + if (flag & AT_SYMLINK_NOFOLLOW) > + error = vfs_lstat_fd(dfd, filename, &stat); > + else > + error = vfs_stat_fd(dfd, filename, &stat); > + > + if (!error) > + error = cp_new_stat(&stat, statbuf); > + > +out: > + return error; > +} > >Unfortunately, I cannot find an explanation as to why these calls were >added. From what I see here, I'm guessing that new functionality was >originally needed to allow fstatat to follow (or not follow) symlinks. > >Looking at the tip of the Linux repository, I can see that more >functionality was built on top of the system call. For instance, >AT_EMPTY_PATH, AT_NO_AUTOMOUNT, and AT_SYMLINK_NOFOLLOW are all options >now (which seems to agree with man pages). There also appears to be an >issue with architectures depending on if they're 64-bit or 32-bit; some >architectures prefer fstatat64 instead of newfstatat. So, it looks like >the kernel chooses a buffer size depending on which system call is >invoked. If gem5 calls the wrong host system call internally (with the >GLIBC wrappers), it will likely clobber the simulated memory and cause >silent memory corruption. The key is to ensure that the host, simulator, >and application all are expecting to use the same buffer size or you'll >need to code around it to accommodate. > >The best thing to do is to probably pull down the Linux source and decide >what's best for yourself; the system call implementations for these >functions still reside in "linux/fs/stat.c". Essentially, you need to >figure out how the options are really being handled internally and then >emulate that behavior in gem5; you'll also need to understand the >contract between GLIBC and the kernel. There usually is not too much >documentation (in the kernel or GLIBC) so I've had to resort to searching >through source before to figure it out. > >Regards, >Brandon > >-----Original Message----- >From: gem5-dev [mailto:[email protected]] On Behalf Of Sooraj >Puthoor >Sent: Wednesday, April 20, 2016 5:27 PM >To: [email protected] >Subject: [gem5-dev] Question about newfstatat() syscall > >Hi all, > >I am trying to run a benchmark in gem5 and while running the benchmark, I >am getting “fatal: syscall newfstatat (#262) unimplemented” error. > >It seems gem5 has a "fstatat()" syscall defined but no definition for " >newfstatat()" exists. So, I was thinking of redirecting the "newstatat()" >syscall to the already defined "fstatat()" syscall. I am not sure if this >the correct approach and would like to know the thoughts of folks who >might have already experienced same/similar problem. > >Another option is to try to remove the syscall from the benchmark by >modifying the code and/or recompiling the code. But this syscall comes >from a pre-compiled library that I am using and I would go down the path >of recompiling that library only as my last option.... :) > >Thank you >-Sooraj Puthoor >_______________________________________________ >gem5-dev mailing list >[email protected]<mailto:[email protected]> >http://m5sim.org/mailman/listinfo/gem5-dev > >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
