Both of these issues come up if you try to use the m5 writefile command with an absolute path somewhere "interesting".
First, the m5 utility uses the same filename/path for both what to read inside the simulation, and what to write to the host file system. If the path is absolute, that could mean that the simulation will read, say, /foo/bar which might exist, but then gem5 will try to write to that same absolute path on the host. That will fail, and then an assert will fire, killing the simulation. I'd suggest a two pronged approach to solving this problem. First, we should disallow absolute paths when writing files to the host in this way. The writefile implementation tries to keep the files it creates in an output directory, and absolute paths defeat that. Additionally, I think the m5 utility should optionally accept two paths, the internal path and the external one. If there's only one path given, then that would be used as both. This way, if you want to write out a file using an absolute path, you can use that for the internal path and use a relative path for what goes on the host. The other issue is that the OutputFile class will attempt to open the file it's given, and then asserts that the file was actually opened. In this case, failing to open the file should just cause an error to be returned into the simulation, not cause the simulator to crash. That's a little bit tricky since the problem is detected in the constructor, but I think iostream does that by having a flag which says whether the stream is any good. We could do the same thing and then react to a failure to open the stream in a situationally appropriate way. What do you think? Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
