I'll post a diff to fix the SCons stuff very soon. Just compiling stuff to make sure it works.
The biggest problem with two namespaces is that it's a lot of code to manage to support both of them. The debug flags stuff is all over the place: scons to generate the flags files, command line options, gdb commands, C++ classes, and probably more. I think we'll be able to work through the confusion. Nate On Wed, Jun 1, 2011 at 9:40 PM, Steve Reinhardt <[email protected]> wrote: > 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 <[email protected]> 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" <[email protected]> >> 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 <[email protected]>: >>> >>>> 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 >>>> [email protected] >>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>> >>> >>> >>> _______________________________________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/gem5-dev >> > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
