OK, now that I'm at a keyboard: if we change the scons thing from TraceFlag() to DebugFlag(), then there's one set of flags with one set of names, it's all debug flags. Some (currently most) of them are only used to control DPRINTFs, but they could be used for other things, and the same flag could in theory be used for both DPRINTFs and other things.
All the --trace-* options solely control things related to DPRINTFs and/or exec tracing (I believe), so that's consistent too. It might not be the simplest scheme ever, but it sounds simpler than having distinct debug flags and trace flags. Steve On Wed, Jun 1, 2011 at 8:15 PM, Steve Reinhardt <ste...@gmail.com> wrote: > On my phone, so I'll be brief, but just fixing the scons to be consistent > sounds good to me. > > On Jun 1, 2011 6:55 PM, "Gabriel Michael Black" <gbl...@eecs.umich.edu> > wrote: >> So, I think part of the confusion is that there are two names now, >> debug flags and trace flags, but they're different views of the same >> mechanism (yes? no?) It seems like the --trace* options are like the >> --debug* options, except their intended use is a subset of --debug*, >> specifically DPRINTFs. What about returning the DPRINTF ones to >> --trace-flags, etc., and introducing a separate parallel set of >> options and namespace for the debug stuff? There's some macro or >> something to check if trace flags are turned on, and that encourages >> their use as debug flags (although I think that use is minimal in the >> current code). We could introduce a new DEBUG_ON() macro (or a better >> name) and optionally eliminate the trace oriented one or make it >> internal to DPRINTFs only. I can think of some valid uses for keeping >> it like blocks of DPRINTFs like Ali added recently, but it blurs the >> line and could add to the confusion. >> >> By having two parallel systems, even though they're a bit redundant >> where they overlap, I think it introduces a clear conceptual >> separation between the two. Then it's clear what trace flags are for >> and when to use them, and also what debug flags are for and when to >> use them. >> >> We really have two different ideas budding off from each other >> (controlling tracing and debug features), and by partially bundling >> them together and partially distinguishing them that leads to >> confusion. The mental model is different from the way you have to >> control things, and trying to reconcile the two views makes the system >> hard to reason about. >> >> Gabe >> >> Quoting nathan binkert <n...@binkert.org>: >> >>> Ok, there has been a lot of confusion about debug flags and trace >>> flags. I changed the way the flags stuff worked from a compile >>> perspective which required me to make changes throughout the tree, so >>> I took the opportunity to rename the trace flags to debug flags. The >>> idea behind the change was that the flags can be used for things other >>> than tracing (I use them for breakpoints) and there is only one >>> namespace, so I just renamed it to debug (people did review that >>> change). >>> >>> So, I renamed --trace-flags to --debug-flags and --trace-flags-help to >>> --debug-flags-help. --trace-start, --trace-file, and --trace-ignore >>> stayed the same because those only affect the tracing portion of the >>> debugging stuff. I never renamed the TraceFlags SCons option to >>> DebugFlags. >>> >>> So, how do we clear up the confusion? Should I just fix the SCons >>> thing and people will just learn? Should I change the name back? >>> (There are a ton of places where this would change). >>> >>> Anyone care? >>> >>> Nate >>> _______________________________________________ >>> gem5-dev mailing list >>> gem5-dev@m5sim.org >>> http://m5sim.org/mailman/listinfo/gem5-dev >>> >> >> >> _______________________________________________ >> gem5-dev mailing list >> gem5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
