Hi Brendan, I have attached a patch in this email. It doesn't change the current behavior when debug=1 is specified. If debug=2 is specified, it uses -O0 if (gcc <4.8) and -Og (if gcc >4.8) and -ggdb3 as compilation flags. The changes are in ptlsim/SConstruct and qemu/SConstruct
Thanks, - Bhushan On Fri, Feb 1, 2013 at 11:54 AM, Brendan Fitzgerald <[email protected] > wrote: > Hi, > > Anyone is free to modify the files to their heart's content, the issue > that would arise with this suggestion is that it would add increased > complexity in the SCons script. > I recently had some issues with a newer version a gcc breaking another > project I was working on and because of this I'd prefer not to have to do > checks for various versions. > > I would be open to looking into this if we were provided either a patch or > pull request from github. While I want to make MARSS the best architectural > simulator available, I only have so much free time. > > Brendan > > On Fri, Feb 1, 2013 at 2:45 PM, Vidyabhushan Mohan > <[email protected]>wrote: > >> I ran some more debugging sessions and found that using -O0 is painfully >> slow (atleast twice slower compared to O1). I think which should keep both >> the options with the default being -O (as it is currently). >> On a similar note, GCC 4.8 has introduced -Og for superior debugging >> experience. (http://gcc.gnu.org/gcc-4.8/changes.html). Anyone have an >> idea of how good it is. If it's good, then we could modify the script to >> check for gcc version and use -Og if we use gcc 4.8 or higher. >> >> - Bhushan >> >> >> On Fri, Feb 1, 2013 at 11:17 AM, Stephan Diestelhorst < >> [email protected]> wrote: >> >>> Vidyabhushan Mohan wrote on Wednesday 30 January 2013, 17:39:47: >>> > Hi, >>> > I have been using Marss to simulate parsec/spec workloads and so far >>> things >>> > have been great. I was debugging one of my simulation runs in debug >>> mode >>> > (scons debug=1 core=8) but I found out that most of the local >>> variables and >>> > some of the function arguments were optimized out and I had to resort >>> to >>> > debugging the assembly. When I checked the script in >>> ptlsim/SConstruct, I >>> > see this piece of code (lines 33-38): >>> > >>> > >>> > if int(debug): >>> > env.Append(CCFLAGS = '-g') >>> > >>> > # If debugging level is 1 then do optimize >>> > >>> > if int(debug) == 1: >>> > env.Append(CCFLAGS = '-O') >>> > >>> > >>> > Was it intentional to *enable* optimization when debug =1 is specified? >>> > Since I do not want any optimizations enabled in the *debug* build, I >>> could >>> > sidestep this by specifying, for example debug =2. But I still wanted >>> to >>> > confirm if enabling optimization (for debug=1) was intentional. If not, >>> > perhaps we could change it to -O0. >>> >>> Personally I find that -O0 code is a pain to look at, but I do rely on >>> the assertions and extra printouts. Furthermore, I am almost always >>> looking at the assembly directly... >>> >>> So maybe having both options (explicitly) would be good? >>> >>> Stephan >>> >>> >>> >> >> _______________________________________________ >> http://www.marss86.org >> Marss86-Devel mailing list >> [email protected] >> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >> >> >
debug.patch
Description: Binary data
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
