It looks like you've set a lot of these to ignoreFunc. Could you please
walk me through why those system calls are ignorable? Also, with the
stat64 syscall, did you verify that the alignment, etc, of the structure
came out right in the simulated memory? Those have historically been
very
This value was actually based off how Linux set up an actual process on
a real machine. We have a tool that runs processes on a real machine and
compares their execution with M5. I calibrated those constants to make
the execution match exactly all the way through. That said, there might
be
I never messed around with the ioctl stuff. What do other M5 devs think?
Nate? Steve? Ali?
Gabe
Vince Weaver wrote:
The current ioctl implementation is somewhat BSD-centric. The few IOCTL
values being checked have no Linux equivelant. This changes things to
just assume that most ioctl's
This looks fine other than the fact that you didn't put comments in
there like the existing flags. Those are for doxygen, I think. The
mapping happens in the openFunc on these lines:
// translate open flags
for (int i = 0; i OS::NUM_OPEN_FLAGS; i++) {
if (tgtFlags
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
*
This generally looks ok, as long as the constant values check out. What
was the binary trying to accomplish with setrlimit? Or in other words is
it 100% safe (in that case at least) to ignore it?
Gabe
Vince Weaver wrote:
Just a re-send of my sparc rlimit/rusage patch.
diff -r 03c418c51f80
I did send in a patch for this syscall, yes. I used writeBlob to send the
value back to memory.
Incidentally, I saw Vince needed ftruncate64 to be implemented. I also
sent in a patch for that too. Do you want me to do anything with those
patches or can they just be added as they are (do I
In general, I'm fine with ignoring things and hoping it works. I
think we should probably change the warn to warn_once.
Similarly, some of the syscalls that we're ignoring should probably
have a warning.
Maybe unimplementedFunc should really just be warn_once plus return error?
Any other
I did send in a patch for this syscall, yes. I used writeBlob to send the
value back to memory.
Incidentally, I saw Vince needed ftruncate64 to be implemented. I also
sent in a patch for that too. Do you want me to do anything with those
patches or can they just be added as they are (do I do
On Tue, Sep 22, 2009 at 11:38 PM, Gabe Black gbl...@eecs.umich.edu wrote:
I think there's been at least a superficial effort to
factor out the common parts and template on, say, an ISA's definition of
a particular data structure as necessary, but pulling the whole thing
into a common spot for
Hi everyone,
It seems that we're getting more and more contributions from people
and we need a better way to manage patches so they don't get dropped
on the floor.
The biggest problem is probably that a contributor often doesn't seem
to hook up with a specific developer to get a given patch into
changeset f4de76601762 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=f4de76601762
description:
arch: nuke arch/isa_specific.hh and move stuff to generated
config/the_isa.hh
diffstat:
125 files changed, 208 insertions(+), 163 deletions(-)
SConstruct
Frequently on system calls that only return one thing the return code is
placed in the return register and the value is placed in another register.
We call these ReturnValueReg and SyscallSuccessReg. If there are only two
return values sometimes SyscallPseudoReturnReg is used. Which is a long way
We don't do anything with the ioctl's at the moment, so picking certain
ones to do nothing with doesn't have much value. A warning is good as this
and the other functions that we're ignoring could be hiding bugs and it
would be nice to have the print statement to remind us it could be a
problem.
For TTY-related ioctls, returning ENOTTY is the right behavior, so
there's no need to print a warning. To me it's a step backward to
start printing a warning for something that we're actually handling
correctly. If we're not properly identifying which ioctls are
TTY-related, I'd rather try and
I meant to add that changing the default behavior for unrecognized
ioctls from a fatal error to a warning is fine by me though.
Steve
On Wed, Sep 23, 2009 at 9:13 AM, Steve Reinhardt ste...@gmail.com wrote:
For TTY-related ioctls, returning ENOTTY is the right behavior, so
there's no need to
On Tue, 22 Sep 2009, Gabe Black wrote:
This value was actually based off how Linux set up an actual process on
a real machine. We have a tool that runs processes on a real machine and
compares their execution with M5. I calibrated those constants to make
the execution match exactly all the
On Tue, 22 Sep 2009, Gabe Black wrote:
We actually support SSE better than x87 as of fairly recently, so you
might want to get gcc to use that for floating point to get things
working. I have fleshing out x87 on my hypothetical to do list, but I
don't know how long it'll take to get done.
On Wed, 23 Sep 2009, nathan binkert wrote:
In general, I'm fine with ignoring things and hoping it works. I
think we should probably change the warn to warn_once.
I think that's a good idea.
Similarly, some of the syscalls that we're ignoring should probably
have a warning.
Maybe
Quoting Vince Weaver vi...@csl.cornell.edu:
On Tue, 22 Sep 2009, Gabe Black wrote:
This value was actually based off how Linux set up an actual process on
a real machine. We have a tool that runs processes on a real machine and
compares their execution with M5. I calibrated those constants to
On Wed, 23 Sep 2009, Steve Reinhardt wrote:
For TTY-related ioctls, returning ENOTTY is the right behavior, so
there's no need to print a warning. To me it's a step backward to
start printing a warning for something that we're actually handling
correctly. If we're not properly identifying
On Wed, Sep 23, 2009 at 2:49 PM, Vince Weaver vi...@csl.cornell.edu wrote:
In most cases the Linux syscalls are fairly similar across ISA's. The
biggest outlier is Alpha, which unfortunately seems to be the original
version that the rest of m5 cut-and-pasted from.
Worse yet, the original
On Wed, Sep 23, 2009 at 2:53 PM, Vince Weaver vi...@csl.cornell.edu wrote:
On Wed, 23 Sep 2009, Steve Reinhardt wrote:
For TTY-related ioctls, returning ENOTTY is the right behavior, so
there's no need to print a warning. To me it's a step backward to
start printing a warning for something
For TTY-related ioctls, returning ENOTTY is the right behavior, so
there's no need to print a warning. To me it's a step backward to
start printing a warning for something that we're actually handling
correctly. If we're not properly identifying which ioctls are
TTY-related, I'd rather try
Quoting nathan binkert n...@binkert.org:
For TTY-related ioctls, returning ENOTTY is the right behavior, so
there's no need to print a warning. To me it's a step backward to
start printing a warning for something that we're actually handling
correctly. If we're not properly identifying
changeset 60e8bbcae401 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=60e8bbcae401
description:
ruby: Disable all debug output by default
diffstat:
1 file changed, 2 insertions(+), 2 deletions(-)
src/mem/ruby/config/defaults.rb |4 ++--
diffs (21 lines):
diff -r
changeset 9bc3e4611009 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9bc3e4611009
description:
isa_parser: Turn the ISA Parser into a subclass of Grammar.
This is to prepare for future cleanup where we allow SCons to create a
separate grammar class for
changeset a886774d5ae1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a886774d5ae1
description:
ply grammar: Fixup Tokenizer class so you can get lexer arguments
diffstat:
1 file changed, 4 insertions(+)
src/python/m5/util/grammar.py |4
diffs (21 lines):
28 matches
Mail list logo
