Took me a lot longer than it should have in retrospect, but here's the
problem (from --trace-flags=SyscallVerbose):
594199893000: global: opening file /proc/meminfo
594199893000: system.cpu: syscall open returns 4
594200152000: system.cpu: syscall fstat called w/arguments
I added support for this kind of file mapping stuff for the m5 command
so I could load multiple files into the simulator in full system mode.
The python portion of this work could easily be ported to SE mode.
Unless you want diffs now, I'll work on getting this stuff in the tree
after ISCA.
It
No rush... we've lived with this for quite a while, at least we know why now.
On Tue, Nov 18, 2008 at 3:10 PM, nathan binkert [EMAIL PROTECTED] wrote:
I added support for this kind of file mapping stuff for the m5 command
so I could load multiple files into the simulator in full system mode.
That makes a lot of sense. I had thought before about an SE chroot, especially
when I was thinking about getting dynamic linking to work. I think it is sort
of overkill, but it probably wouldn't be -that- bad to implement. It would also
help protect against a crazy defunct simulation destroying
I did some digging and I figured it out. There is a libc function
(posix.1): int sysconf(int name).
The various system parameters you can query vary from the maximum
number of arguments to the number of free physical pages in the
system. Parser doesn't call this function directly, however
I'd vote for 2 since you may get unrealistic results otherwise. I don't think
this is what that person on the mailing list is seeing since they're out of
memory at tick 0.
Gabe
Quoting Ali Saidi [EMAIL PROTECTED]:
I did some digging and I figured it out. There is a libc function
(posix.1):
