> (switching to regular email... these nested conversations via reviewboard > get awkward IMO) > I didn't say I won't complain ;-). However, if we're going to switch, let's > be serious about it and not go halfway. Sounds reasonable.
> It didn't occur to me before that there are several other arguments that get > affected: --trace-help, --trace-start, --trace-file, and --trace-ignore. > Are you planning on just doing s/trace/debug/ on all of these? I guess > that's OK; the only one I worry about is --debug-help, which seems like it's > asking for a lot more than just listing flags. I don't think we need error > messages on all of them (since none of them make sense w/o --trace-flags > anyway). I agree. I'd only put the error message on --trace-flags. Instead of --debug-help, we could just do --debug-flags-help > The other interesting thing is that --debug-break now fits in with this > group, for better or for worse. I like that it's not so lonely anymore, but > it's the only one that's not related to flags. I was actually thinking that it was nice. Debug::breakpoint() was something that I wanted to enable/disable with flags. For example, it'd be nice to have intelligently placed breakpoints for things like startup(), module initialization (if using m5 as a python lib), instantiation, etc. The one that I want the most is startup() so that the simulator stops and you can do things like call functions. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
