[gem5-dev] Debug Flags

2011-06-01 Thread nathan binkert
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


Re: [gem5-dev] Debug Flags

2011-06-01 Thread Gabriel Michael Black
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


Re: [gem5-dev] Debug Flags

2011-06-01 Thread Steve Reinhardt
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


Re: [gem5-dev] Debug Flags

2011-06-01 Thread Steve Reinhardt
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


Re: [gem5-dev] Debug Flags

2011-06-01 Thread nathan binkert
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 ste...@gmail.com 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 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

___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev