Good point---obviously this change works better for my use case, but I can see the confusion you point out.  In particular, I can imagine a case where a program creates an output file, then closes and re-opens it, and the re-open will fail since the file did not get created in the cwd.  So now I sort of feel like this ought to be controlled with a command-line flag.  Another alternative would be to have an option to force a cwd change into the output directory, which I think would make this change irrelevant (since output files would then automatically get created in the output dir) and also solve the create/re-open problem, and would only be an issue if your program is reading files in the original dir, but if you specified the cd option then presumably you'd know that you need to fix that.
Thoughts?

I wasn't sure how to feel about this patch. The current output file setup is consistent in that all files specified on the command line to the gem5 binary can use the same relative file paths (e.g. outdir, benchmark input/output, simulator output), so it's easy to reason about. That said, I understand that some benchmarks implicitly specify input and output files and these are often harder to change than the simulator.
Of the options to change output file handling, I feel that a command line option to run from the output directory (default: False) is most desirable, since it doesn't upset any existing scripts.

I think having an option is a good idea. In fact, there could be two different ways to run gem5. 

1) In "wrapper" mode, where output is sent to stdout/stderr and files are read/written in cwd. This would be similar to how docker/pin/etc. works, for instance.

2) In redirect mode where everything (or a subset) is redirected to m5out.
I'm not sure if this totally lines up with what you were saying, Steve. I personally think I would use it similar to your use case anyway.