'-DNDEBUG=0' and '-DDEBUGVM=1'
Locked
'-DNDEBUG=0' and '-DDEBUGVM=1'
 
|
Hi Eliot. I am not sure if I understand correctly these flags, and if I do, then I think the CMake configurations are wrong. First, what are those flags intended for? Which should be tuned on and which one off for both, release and debug ? In Unix/Windows conf, onlt for release, these are set: -DDEBUGVM=0 -DNDEBUG Mac Carbon release -DDEBUGVM=0 -DNDEBUG=1 Mac Cocoa Cog (CocoaIOSCogConfig) debug '-DNDEBUG=1' '-DDEBUGVM=0' Mac Cocoa Cog (CocoaIOSCogConfig) release '-DNDEBUG=1' '-DDEBUGVM=0' Mac Cocoa Cog MT debug -DNDEBUG=0' '-DDEBUGVM=1' Mac Cocoa Cog MT release '-DNDEBUG=0' '-DDEBUGVM=1' So...this is a mess. Mac Cocoa Cog MT, have the same for both release and debug. Is this correct? Mac Cocoa Cog, idem Mac Cocoa Cog MT What is worst, Mac Cocoa Cog MT is the opposite of Mac Cocoa Cog so...i have no idea how this should be, but sounds strange for me Cheers -- Mariano http://marianopeck.wordpress.com |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
On Wed, Apr 13, 2011 at 9:06 AM, Mariano Martinez Peck <[hidden email]> wrote:
NDEBUG is a Mac OS X/FreeBSD/Linux flag that controls asserts. To get asserts working in Cog it was easiest to use this flag. So if NDEBUG=0 asserts are eliminated and if NDEBUG=1 they are included and cause a warning to be printed to stdout when enabled (via a call to warning). See platforms/Cross/vm/sqAssert.h. Hence NDEBUG=0 for production and NDEBUG=1 for debug and assert VMs.
DEBUGVM is a flag controlling details of code generation for the entry-points that jump from the interpreter into machine code. Seer DEBUGVM and Debug in src/vm/cogit.c. I needed this early on in development when the system was flakey. Now I never use it. One might suggest eliminating it but it will probably be useful again when we add new code generators (e.g. for ARM and x86-64). So DEBUGVM=0 for production and assert VMs and either 1 or 0 for debug VMs, depending on what kind of problems you're looking to debug.
HTH Eliot
|
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
Thanks Eliot for the explanation. So, some of those confs are incorrect. I will commit a fix tonight. Mariano On Wed, Apr 13, 2011 at 6:35 PM, Eliot Miranda <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
On 13 April 2011 18:52, Mariano Martinez Peck <[hidden email]> wrote: > > Thanks Eliot for the explanation. So, some of those confs are incorrect. I will commit a fix tonight. > And with comments, comments! :) Thank you both! > Mariano > > On Wed, Apr 13, 2011 at 6:35 PM, Eliot Miranda <[hidden email]> wrote: >> >> >> >> >> On Wed, Apr 13, 2011 at 9:06 AM, Mariano Martinez Peck <[hidden email]> wrote: >>> >>> >>> Hi Eliot. I am not sure if I understand correctly these flags, and if I do, then I think the CMake configurations are wrong. >>> >>> First, what are those flags intended for? Which should be tuned on and which one off for both, release and debug ? >> >> NDEBUG is a Mac OS X/FreeBSD/Linux flag that controls asserts. To get asserts working in Cog it was easiest to use this flag. So if NDEBUG=0 asserts are eliminated and if NDEBUG=1 they are included and cause a warning to be printed to stdout when enabled (via a call to warning). See platforms/Cross/vm/sqAssert.h. Hence NDEBUG=0 for production and NDEBUG=1 for debug and assert VMs. >> DEBUGVM is a flag controlling details of code generation for the entry-points that jump from the interpreter into machine code. Seer DEBUGVM and Debug in src/vm/cogit.c. I needed this early on in development when the system was flakey. Now I never use it. One might suggest eliminating it but it will probably be useful again when we add new code generators (e.g. for ARM and x86-64). So DEBUGVM=0 for production and assert VMs and either 1 or 0 for debug VMs, depending on what kind of problems you're looking to debug. >> HTH >> Eliot >>> >>> In Unix/Windows conf, onlt for release, these are set: >>> -DDEBUGVM=0 -DNDEBUG >>> >>> Mac Carbon release >>> -DDEBUGVM=0 -DNDEBUG=1 >>> >>> Mac Cocoa Cog (CocoaIOSCogConfig) debug >>> '-DNDEBUG=1' '-DDEBUGVM=0' >>> >>> Mac Cocoa Cog (CocoaIOSCogConfig) release >>> '-DNDEBUG=1' '-DDEBUGVM=0' >>> >>> Mac Cocoa Cog MT debug >>> -DNDEBUG=0' '-DDEBUGVM=1' >>> >>> Mac Cocoa Cog MT release >>> '-DNDEBUG=0' '-DDEBUGVM=1' >>> >>> >>> So...this is a mess. Mac Cocoa Cog MT, have the same for both release and debug. Is this correct? >>> Mac Cocoa Cog, idem Mac Cocoa Cog MT >>> >>> What is worst, Mac Cocoa Cog MT is the opposite of Mac Cocoa Cog >>> >>> so...i have no idea how this should be, but sounds strange for me >>> >>> Cheers >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Best regards, Igor Stasenko AKA sig. |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
I've just commited the fix, but not the comment ;) Seriously, I don't know how we can document this kind of things. Putting such comments in #compilerFlagsRelease or #compilerFlagsRelease doesn't make sense because they are aprox. 12 implementaions...I don't want to copy paste to all of them. Only in one? it doesn't make sense because people won't see it. So..how we document this kind of things? I have no idea. The same with class comments. There are so many classes that copy pasting or documenting only one doesn't make sense. The only thing I though is doing something like this: compilerFlagsRelease ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks' '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer' '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse' '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP' '-DNDEBUG=0' , self debugVMFlag: true, '-DCOGMTVM=0' '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4') >>debugVMFlagEnable: boolean "THIS flag is blagh...blh..." ^ '-DDEBUGVM=', boolean asNumber asString or something like that... cheers Mariano
On Wed, Apr 13, 2011 at 6:57 PM, Igor Stasenko <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
|
|
On 13 April 2011 19:13, Mariano Martinez Peck <[hidden email]> wrote: > I've just commited the fix, but not the comment ;) > > Seriously, I don't know how we can document this kind of things. > Putting such comments in #compilerFlagsRelease or #compilerFlagsRelease > doesn't make sense because they are aprox. 12 implementaions...I don't want > to copy paste to all of them. Only in one? it doesn't make sense because > people won't see it. So..how we document this kind of things? I have no > idea. > > The same with class comments. There are so many classes that copy pasting or > documenting only one doesn't make sense. > The root class is enough. A subclasses should just say something like 'i am special for ___that__ and do things differently because i want __that__'. > The only thing I though is doing something like this: > > > compilerFlagsRelease > ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks' > '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer' > '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse' > '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX' > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST' > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP' > '-DNDEBUG=0' , self debugVMFlag: true, '-DCOGMTVM=0' > '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4') > >>>debugVMFlagEnable: boolean > "THIS flag is blagh...blh..." > ^ '-DDEBUGVM=', boolean asNumber asString > > or something like that... > > This knowledge is important. It of course a question where to put that, but that's exactly why i didn't wanted to use autoconf to generate config.h file, which contains like 50 various flags, without any clues, where these flags being used, and in what situations they should be turned on or off.. So, later we could step over every flag and properly document them, and like that, for people who will come later, we will have an idea what are need to deal with and why. > cheers > > Mariano > -- Best regards, Igor Stasenko AKA sig. |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
Hi guys. I don't know why but with CMakeVMMaker the asserts are not working. I can see the flags are being set correct in CmakeList.txt: add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM) I modified the StackInterpreter to this: lookupMethodInClass: class | currentClass dictionary found | <inline: false> self asserta: '42' = 'cuarenta y tres'. self assert: 'mariano' = 'esta perdido'. self print: 'grrrr'; cr. ..... and only 'grrr' is printed. The TWO previous assert are ignored. I may be doing something very stupid... thanks in advance, Mariano On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
On 26 April 2011 03:05, Mariano Martinez Peck <[hidden email]> wrote: > > Hi guys. I don't know why but with CMakeVMMaker the asserts are not working. I can see the flags are being set correct in CmakeList.txt: > > add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM) > AFAIK, code checks #ifdef NDEBUG which means 'if defined NDEBUG' and so it doesn't matters if it = 1 or = 0 because it is defined, but don't cares which value. Also, NDEBUG and DEBUGVM should be mutually exclusive? If first stands for 'no-debug' and second stands for 'debug vm'.. > I modified the StackInterpreter to this: > > lookupMethodInClass: class > | currentClass dictionary found | > <inline: false> > self asserta: '42' = 'cuarenta y tres'. > self assert: 'mariano' = 'esta perdido'. > self print: 'grrrr'; cr. > > ..... > > and only 'grrr' is printed. The TWO previous assert are ignored. > > I may be doing something very stupid... > > thanks in advance, > > Mariano > > > > On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 13 April 2011 19:13, Mariano Martinez Peck <[hidden email]> wrote: >> > I've just commited the fix, but not the comment ;) >> > >> > Seriously, I don't know how we can document this kind of things. >> > Putting such comments in #compilerFlagsRelease or #compilerFlagsRelease >> > doesn't make sense because they are aprox. 12 implementaions...I don't want >> > to copy paste to all of them. Only in one? it doesn't make sense because >> > people won't see it. So..how we document this kind of things? I have no >> > idea. >> > >> > The same with class comments. There are so many classes that copy pasting or >> > documenting only one doesn't make sense. >> > >> >> The root class is enough. >> A subclasses should just say something like 'i am special for >> ___that__ and do things differently because i want __that__'. >> >> >> > The only thing I though is doing something like this: >> > >> > >> > compilerFlagsRelease >> > ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks' >> > '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer' >> > '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse' >> > '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX' >> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST' >> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP' >> > '-DNDEBUG=0' , self debugVMFlag: true, '-DCOGMTVM=0' >> > '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4') >> > >> >>>debugVMFlagEnable: boolean >> > "THIS flag is blagh...blh..." >> > ^ '-DDEBUGVM=', boolean asNumber asString >> > >> > or something like that... >> > >> > >> >> This knowledge is important. It of course a question where to put that, >> but that's exactly why i didn't wanted to use autoconf to generate >> config.h file, which contains like 50 various flags, >> without any clues, where these flags being used, and in what >> situations they should be turned on or off.. >> >> So, later we could step over every flag and properly document them, >> and like that, for people who will come later, we will have an idea >> what are need to deal with and why. >> >> > cheers >> > >> > Mariano >> > >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Best regards, Igor Stasenko AKA sig. |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko <[hidden email]> wrote:
NO!! NO!! NO!! [ :) ]. I said earlier, NDEBUG is a linux-ism for enabling asserts. See /usr/include/assert.h. So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues.
DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code. Arguably it could be eliminated but it'll be useful when we port to new ISAs. I said all this last week. Please take note this time :) best, Eliot
|
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
In reply to this post by Mariano Martinez Peck
Hi Mariano: On 26 Apr 2011, at 02:05, Mariano Martinez Peck wrote: > Hi guys. I don't know why but with CMakeVMMaker the asserts are not working. I can see the flags are being set correct in CmakeList.txt: > > -DNDEBUG=1 I think Igor and Eliot already answered the question, but since nobody pointed you at this document, I will do it. Might help for future questions: http://linux.die.net/man/3/assert Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
On Tue, Apr 26, 2011 at 7:56 AM, Stefan Marr <[hidden email]> wrote:
Hi Stefan. No, they didn't answer, or yes, they answer but I am so newbie that I don't see it. My question was why I didn't see in the gdb console those outputs of those asserts. If I am compiling with -DNDEBUG=1 I expect the asserts() to be evaluating. And even more, asserta() seems to evaluates always. So...why if I did this: lookupMethodInClass: class | currentClass dictionary found | <inline: false> self asserta: '42' = 'cuarenta y tres'. self assert: 'mariano' = 'esta perdido'. self print: 'grrrr'; cr. ..... and compile the vm and I fire up an iamge...why only 'grrr' is printed ?? The TWO previous assert are ignored, even the asserta() If this was answered I thanks someone that could explain it again for me :) thanks in advance Mariano but since nobody pointed you at this document, I will do it. Might help for future questions: -- Mariano http://marianopeck.wordpress.com |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
Hi Mariano: On 26 Apr 2011, at 09:53, Mariano Martinez Peck wrote: > If I am compiling with -DNDEBUG=1 I expect the asserts() to be evaluating. NDEBUG is a short form for NO debug, I suppose. Let me cite the manpage: >> If the macro NDEBUG was defined at the moment <assert.h> was last included, the macro assert() generates no code, and hence does nothing at all. << Thus, -DNDEBUG=0 and -DNDEBUG=1, as well as -DNDEBUG=foo have all the same effect: NO DEBUG, no assertions. > And even more, asserta() seems to evaluates always. I don't know asserta(), I suppose it is `assert always`? The only thing I can tell you here is, that you probably need to refer to its implementation. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
On Tue, Apr 26, 2011 at 10:18 AM, Stefan Marr <[hidden email]> wrote:
Thanks Stefan. In fact, you were right. If I DO NOT define DNDEBUG, assertions. If I define it (with whatever value), no assertions. Now, I think that I was to naive to understand Eliot's first answer: " NDEBUG is a Mac OS X/FreeBSD/Linux flag that controls asserts. To
get asserts working in Cog it was easiest to use this flag. So if
NDEBUG=0 asserts are eliminated and if NDEBUG=1 they are included and
cause a warning to be printed to stdout when enabled (via a call to
warning). See platforms/Cross/vm/sqAssert.h. Hence NDEBUG=0 for
production and NDEBUG=1 for debug and assert VMs.
"So..I should have NOT understood them literal "Hence NDEBUG=0 for production and NDEBUG=1 for debug" but instead that for debug I DO NOT have to define NDEBUG but I do for production ? And even more, when Igor said "and so it doesn't matters if it = 1 or = 0 because it is defined, but don't cares which value." he was correct.
yes Thanks Stefan Mariano
-- Mariano http://marianopeck.wordpress.com |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
In reply to this post by Eliot Miranda-2
On 26 April 2011 04:03, Eliot Miranda <[hidden email]> wrote: > > > > On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 26 April 2011 03:05, Mariano Martinez Peck <[hidden email]> wrote: >> > >> > Hi guys. I don't know why but with CMakeVMMaker the asserts are not working. I can see the flags are being set correct in CmakeList.txt: >> > >> > add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM) >> > >> >> AFAIK, code checks >> >> #ifdef NDEBUG >> >> >> which means >> 'if defined NDEBUG' >> >> and so it doesn't matters if it = 1 or = 0 >> because it is defined, but don't cares which value. >> >> Also, >> NDEBUG and DEBUGVM should be mutually exclusive? > > NO!! NO!! NO!! [ :) ]. I said earlier, NDEBUG is a linux-ism for enabling asserts. See /usr/include/assert.h. So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues. > DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code. Arguably it could be eliminated but it'll be useful when we port to new ISAs. > I said all this last week. Please take note this time :) But hey, i insist that they are mutually exclusive. See, if i want to build a debug version of VM, i should use -DDEBUGVM=1 but should not use -DNDEBUG because otherwise all assertions will be suppressed, which is not what i would want in debug version of VM. AFAIK, windows also using NDEBUG, but my main comment was about that it is used wrongly. The check if defined(NDEBUG) will always pass whether you use -DNDEBUG=1 or -DNDEBUG=0 because it checks if given symbol are defined, it doesn't cares about its value!!! So, a proper use would be to either omit -DNDEBUG at all, or include it. But not like currently, changing its value between 0 or 1. Here the code from assert.h: #ifdef NDEBUG #define assert(e) ((void)0) #else .... And here the sample code for testing it: >> cat a.c #include <stdio.h> int main() { #ifdef NDEBUG printf ("NDEBUG defined\n"); #endif return 0; } Now see what happens: gcc a.c ./a.out <no output> gcc -DNDEBUG=0 a.c ./a.out NDEBUG defined gcc -DNDEBUG=1 a.c ./a.out NDEBUG defined gcc -DNDEBUG=1 a.c ./a.out NDEBUG defined gcc -DNDEBUG=ZORK a.c ./a.out NDEBUG defined > best, > Eliot >> >> If first stands for 'no-debug' and second stands for 'debug vm'.. >> >> >> > I modified the StackInterpreter to this: >> > >> > lookupMethodInClass: class >> > | currentClass dictionary found | >> > <inline: false> >> > self asserta: '42' = 'cuarenta y tres'. >> > self assert: 'mariano' = 'esta perdido'. >> > self print: 'grrrr'; cr. >> > >> > ..... >> > >> > and only 'grrr' is printed. The TWO previous assert are ignored. >> > >> > I may be doing something very stupid... >> > >> > thanks in advance, >> > >> > Mariano >> > >> > >> > >> > On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko <[hidden email]> wrote: >> >> >> >> On 13 April 2011 19:13, Mariano Martinez Peck <[hidden email]> wrote: >> >> > I've just commited the fix, but not the comment ;) >> >> > >> >> > Seriously, I don't know how we can document this kind of things. >> >> > Putting such comments in #compilerFlagsRelease or #compilerFlagsRelease >> >> > doesn't make sense because they are aprox. 12 implementaions...I don't want >> >> > to copy paste to all of them. Only in one? it doesn't make sense because >> >> > people won't see it. So..how we document this kind of things? I have no >> >> > idea. >> >> > >> >> > The same with class comments. There are so many classes that copy pasting or >> >> > documenting only one doesn't make sense. >> >> > >> >> >> >> The root class is enough. >> >> A subclasses should just say something like 'i am special for >> >> ___that__ and do things differently because i want __that__'. >> >> >> >> >> >> > The only thing I though is doing something like this: >> >> > >> >> > >> >> > compilerFlagsRelease >> >> > ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks' >> >> > '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer' >> >> > '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse' >> >> > '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX' >> >> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST' >> >> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP' >> >> > '-DNDEBUG=0' , self debugVMFlag: true, '-DCOGMTVM=0' >> >> > '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4') >> >> > >> >> >>>debugVMFlagEnable: boolean >> >> > "THIS flag is blagh...blh..." >> >> > ^ '-DDEBUGVM=', boolean asNumber asString >> >> > >> >> > or something like that... >> >> > >> >> > >> >> >> >> This knowledge is important. It of course a question where to put that, >> >> but that's exactly why i didn't wanted to use autoconf to generate >> >> config.h file, which contains like 50 various flags, >> >> without any clues, where these flags being used, and in what >> >> situations they should be turned on or off.. >> >> >> >> So, later we could step over every flag and properly document them, >> >> and like that, for people who will come later, we will have an idea >> >> what are need to deal with and why. >> >> >> >> > cheers >> >> > >> >> > Mariano >> >> > >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko AKA sig. >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > -- Best regards, Igor Stasenko AKA sig. |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
On Tue, Apr 26, 2011 at 6:21 AM, Igor Stasenko <[hidden email]> wrote:
You can insist all you like but you're wrong. NDEBUG controls assertions and these are orthogonal to the enilopmart debugging introduced by using DEBUGVM. Simple as that. They are *not* mutually exclusive.
See, if i want to |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
On 26 April 2011 19:01, Eliot Miranda <[hidden email]> wrote: > > > > On Tue, Apr 26, 2011 at 6:21 AM, Igor Stasenko <[hidden email]> wrote: >> >> On 26 April 2011 04:03, Eliot Miranda <[hidden email]> wrote: >> > >> > >> > >> > On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko <[hidden email]> wrote: >> >> >> >> On 26 April 2011 03:05, Mariano Martinez Peck <[hidden email]> wrote: >> >> > >> >> > Hi guys. I don't know why but with CMakeVMMaker the asserts are not working. I can see the flags are being set correct in CmakeList.txt: >> >> > >> >> > add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM) >> >> > >> >> >> >> AFAIK, code checks >> >> >> >> #ifdef NDEBUG >> >> >> >> >> >> which means >> >> 'if defined NDEBUG' >> >> >> >> and so it doesn't matters if it = 1 or = 0 >> >> because it is defined, but don't cares which value. >> >> >> >> Also, >> >> NDEBUG and DEBUGVM should be mutually exclusive? >> > >> > NO!! NO!! NO!! [ :) ]. I said earlier, NDEBUG is a linux-ism for enabling asserts. See /usr/include/assert.h. So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues. >> > DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code. Arguably it could be eliminated but it'll be useful when we port to new ISAs. >> > I said all this last week. Please take note this time :) >> >> >> But hey, i insist that they are mutually exclusive. > > You can insist all you like but you're wrong. NDEBUG controls assertions and these are orthogonal to the enilopmart debugging introduced by using DEBUGVM. Simple as that. They are *not* mutually exclusive. > Eliot, i understand this stuff. Now you taking my words too literally. I meant to say that for existing cmake configurations they should be mutually exclusive. But for current variants for release we should have: a) turn debugging off (-DDEBUGVM=0) b) suppress assertions (-DNDEBUG) and when building VM for debugging we doing otherwise: - turn all debugging on (-DDEBUGVM=1) - enable assertions (omit defining -DNDEBUG) so in the above two configurations its easy to see that these two options are mutually exclusive. And of course, in case of need, one can create configuration where you can use different combination of these two flags, but the above two is most logical choice for release and debug versions of VM configs. -- Best regards, Igor Stasenko AKA sig. |
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
On Tue, Apr 26, 2011 at 10:29 AM, Igor Stasenko <[hidden email]> wrote:
Ah, agreed :) Sorry :)
|
Re: '-DNDEBUG=0' and '-DDEBUGVM=1'
|
|
On Tue, Apr 26, 2011 at 7:40 PM, Eliot Miranda <[hidden email]> wrote:
Yes, exactly. Finally I understood. So...I will commit the fix becuase now CMake confs are wrong. Cheers Mariano
-- Mariano http://marianopeck.wordpress.com |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |