Your collective trust of m5 guru-ness was right. I am now saving file
offset, host flags, mode, name and able to bring it back from
checkpoint. Most of my changes were localized to the alloc_fd and
free_fd function in process.c by including a few more parameters. I just
have to correctly handle pipe, and I will post a diff if any are
interested. I went with the parallel array technique to just avoid too
many changes, and that may reduce desirability. Let me know.
-R
Steve Reinhardt wrote:
Hmm, yea, I think making this work robustly in all cases is
non-trivial, but you can probably at least fix your bug pretty easily.
Basically the fd_map array in Process is the key; all the non-negative
entries in this array are open file descriptors in the target process,
and the value of the entry is the file descriptor in m5 that it
corresponds to.
Rather than saving and restoring this array literally, like we are now
(which actually makes no sense), you should serialize for every
non-negative fd the filename, mode (ro, rw) and offset, then reopen
the file, seek to that offset, and store the new fd in the array entry
in the unserialize method.
To have the filename and mode around you'll need to save that in a
parallel array (or better expand fd_map to a struct) on the "open"
calls. You'll have to special-case stdin/stdout etc if they don't get
reassigned.
To be really thorough you'll have to handle dup'd fds, etc. specially
too, but that's probably optional in terms of getting past your bug.
Hope that helps...
Steve
On Nov 14, 2007 9:38 PM, Rick Strong <[EMAIL PROTECTED]> wrote:
All right, I am in the process on understanding how it all works. Where
is a good place to start. I am right now looking through sim/process.*
and sim/syscall_emul* to work backwards to where all the information is
stored. If someone has insight on this system and could offer a brief
description of how it works, it would be very helpful.
-Richard
Nathan Binkert wrote:
When you fix this, pretty please submit a diff :)
I'm pretty sure I figured it out and I'm pretty sure it is related to
file I/O. When we restore from a checkpoint we don't reopen and seek
to the appropriate place in any files we were reading from/writing
to. I bet what is happening is that the benchmark attempts to read
some input data (or maybe write some data) and the file descriptor is
invalid when M5 passes the syscall through to the host OS. The OS
returns an error code which alters the path of the benchmark and it
exits early. It shouldn't be too hard to fix but I don't have time to
do it at the moment. You would need to keep track of all the open
files paths and modes and add the paths/modes to the checkpoint along
with the current position (via tell()). Upon restoring from a
checkpoint you would reopen the files and seek() to the appropriate
place in the file.
Ali
On Nov 14, 2007, at 10:02 PM, Rick Strong wrote:
When I take a checkpoint in AtomicSimpleCPU (m5_2.0b4) at
curTick=100015476500 (approx. 200,000,000 insts into the binary) in
mcf, and resume execution in any CPU model, I get an exit syscall
(syscall trace included below) at cycle 100522711000 (approx 1014345
insts into execution). What is strange is that if I run
AtomicSimpleCPU through this point (from start), I have no problems.
Any ideas on either the problem or how to debug?
It turns out that the same problem happens for checkpoints in twolf
about 200,000,000 insts into the binary. A resume has some file i/o
and an untimely exit. Both problems seem related to file i/o and
then an exit call. Is it possible that some system call is not
implemented and defaulting to exit. I included the syscall trace for
twolf for any interested parties:
I have resumed both checkpoints, immediately created new
checkpoints, and they diff clean (except for order of the ptable
entries).
I am right now working on getting an EXEC trace for mcf, one from
checkpoint and one executing from the beginning to find any
differences.
TWOLF syscall trace
"
100285445500: system.cpu: pc 4832275812 syscall read called
w/arguments 4,5368834056,8192,1
100285445500: system.cpu: syscall read returns 18446744073709551615
100286500500: system.cpu: pc 4832275812 syscall read called
w/arguments 4,5368834056,8192,5
100286500500: system.cpu: syscall read returns 18446744073709551615
100287514000: system.cpu: pc 4832260836 syscall close called
w/arguments 0,4831383888,1,1048576
100287514000: system.cpu: syscall close returns 0
100287679500: system.cpu: pc 4832260628 syscall write called
w/arguments 1,5368796680,172,1048576
TimberWolfSC version:v4.3a date:Mon Jan 25 18:50:36 EST 1988
Standard Cell Placement and Global Routing Program
Authors: Carl Sechen, Bill Swartz
Yale University
100287679500: system.cpu: syscall write returns 172
100287726500: system.cpu: pc 4832260836 syscall close called
w/arguments 1,4831383888,172,0
" MCF SYSCALL TRACE "
100519102000: system.cpu: syscall read called w/arguments
3,5368799240,8192,7
100519102000: system.cpu: syscall read returns 18446744073709551615
100521401500: system.cpu: syscall obreak called w/arguments
5374902272,0,0,1048576
100521401500: global: Break Point changed to: 0X1405E8000
100521401500: system.cpu: syscall obreak returns 5374902272
100521680500: system.cpu: syscall close called w/arguments
0,4831387472,1,1048576
100521680500: system.cpu: syscall close returns 0
100521846000: system.cpu: syscall write called w/arguments
1,5368778616,119,1048576
100521846000: system.cpu: syscall write returns 119
100521893000: system.cpu: syscall close called w/arguments
1,4831387472,119,0
100521893000: system.cpu: syscall close returns 0
100522014000: system.cpu: syscall close called w/arguments
2,4831387472,0,1048576
100522014000: system.cpu: syscall close returns 18446744073709551615
100522187500: system.cpu: syscall close called w/arguments
3,4831387472,1,1048576
100522187500: system.cpu: syscall close returns 0
100522357000: system.cpu: syscall obreak called w/arguments
5368815616,0,0,1048576
100522357000: global: Break Point changed to: 0X14001A000
100522357000: system.cpu: syscall obreak returns 5368815616
100522623500: system.cpu: syscall sigprocmask called w/arguments
1,18446744073709547831,0,0
warn: ignoring syscall sigprocmask(1, 18446744073709547831, ...)
100522623500: system.cpu: syscall sigprocmask returns 0
100522711000: system.cpu: syscall exit called w/arguments
18446744073709551615,5368739848,2,0
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
