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
