Hot!Ifndef __DEBUG greying out wrong code

Author
NeilVP
New Member
  • Total Posts : 9
  • Reward points : 0
  • Joined: 2012/05/03 22:49:58
  • Location: 0
  • Status: offline
2017/03/27 02:23:15 (permalink)
0

Ifndef __DEBUG greying out wrong code

Trying to debug a project in MPLAB XDE 3.55 and using #ifdef and #ifndef __DEBUG for code options. 
 
Never having used this before my assumptions are that
 
the assertion of __DEBUG is automated by XDE
that greyed out code will NOT be compiled and
that when writing the code that XDE assumes it is NOT a debug build - because I haven't told it to be a debug version anywhere.
 
If my assumptions are correct then I think the "wrong" option within the #ifndef or #ifdef is being greyed out.
 
The simple fix (which I have resorted to) is to use #ifndef when I think I should use #ifdef but this seems wrong to me and may lead to problems later.
 
Are my assumptions wrong and do I have to tell XDE explicitly that builds are not debug by default?
 
Many thanks
 
Neil
 
#1

19 Replies Related Threads

    rodims
    Super Member
    • Total Posts : 827
    • Reward points : 0
    • Joined: 2009/02/10 11:08:59
    • Location: 51.9627, 7.6262
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/03/27 03:32:12 (permalink)
    +2 (2)
    Looking at my source code (MpLabX 3.55 and 3.51, XC16 1.31) I'm surprised that I must confirm this problem.
    Unfortunately I cannot tell when this was introduced. I think it should have been ok some releases ago, but I'm not sure and I don't want to reinstall lots of MpLabX versions.
    Obviously the MpLabX parser thinks __DEBUG is defined (or sees some irrelevant definition), regardless of whether it is e.g. defined in the XC16 compiler command line or not.
     
    NeilVP
    The simple fix (which I have resorted to) is to use #ifndef when I think I should use #ifdef but this seems wrong to me and may lead to problems later.

     
    This is wrong. What you see in the editor is not the compilers truth. It's what the seperate parser thinks, but not what the compiler sees.  Place some wrong code in the corresponding #ifdef then you easily see, what the compiler sees.
     

    #ifdef __DEBUG
        this will cause a syntax error
    #endif

     
    So you must not modify your #ifdefs, instead you must ignore the "grayed out" feature in this case.
    You could create and use your own __MYDEBUG constant, but of course you are loosing some comfort of the MpLabX IDE. 

     
     
     
    #2
    rodims
    Super Member
    • Total Posts : 827
    • Reward points : 0
    • Joined: 2009/02/10 11:08:59
    • Location: 51.9627, 7.6262
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/03/27 05:20:33 (permalink)
    0
    No idea, which setting or bug "virtually" defines the __DEBUG for the IDE (virtually = grayed out by IDE)


    For a test with a 3 liner project, and without any #includes in the one and only source file, the problem is still there.
    I.e. __DEBUG is defined.
     
    Switching my compiler tool chain in 'project properties' to the old C30 (v 3.31):
    -> the __DEBUG is NOT defined  (neither real nor virtual,  i.e. correct)
    Switching compiler tool chain to either XC16 1.26, 1.30, 1.31,
    -> __DEBUG is defined again (virtual only)
     
    Using #undef __DEBUG will also undefine it for the IDE parser (virtual, and real of course)
     
    #3
    moser
    Super Member
    • Total Posts : 259
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/03/27 05:45:24 (permalink)
    +1 (1)
    I guess the described behavior is just the best, which the IDE can do.
     
    The __DEBUG macro is automatically generated by the IDE for a debug build. But the IDE doesn't have a setting or a switch to select a debug build. It just has buttons like "Build for Debugging" or "Debug Project". So the IDE just cannot know whether you currently want to look at your code as for a normal built or whether you currently want to look at it as for debug build, because it doesn't know, which button you are going to press. I think this is the main reason for the problem. Some other IDEs (like e.g. Visual Studio) don't have this problem, because they have a switch for enabling debug.
     
    So what should the IDE do? So should it assume a debug build and define __DEBUG or should it not? No matter how it decides, always one of the #ifdef __DEBUG sections and #ifndef __DEBUG sections will be disabled. And none of the two behaviors is really "correct". 
     
    I think, the typical use case for __DEBUG is to use it with #ifdef. The use of #ifndef __DEBUG is more unlikely. And because of this, the approach was probably just to always set __DEBUG for parsing, because this usually allows you to edit your debug code in the more often used #ifdef __DEBUG section in a more comfortable way with syntax highlighting activated and with IDE support.
    post edited by moser - 2017/03/27 05:51:37
    #4
    NKurzman
    A Guy on the Net
    • Total Posts : 14827
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/03/27 05:49:09 (permalink)
    +1 (1)
    __DEBUG is generated by the IDE not the compiler. It is addded to the command line.
    This means it is never in the code.
    #5
    rodims
    Super Member
    • Total Posts : 827
    • Reward points : 0
    • Joined: 2009/02/10 11:08:59
    • Location: 51.9627, 7.6262
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/03/27 06:21:52 (permalink)
    0
    This is correct. But the problem is that __DEBUG is definitely NOT defined by the command line (nor in the code or includes), but still the the IDE 'grayed out lines' feature thinks that is IS defined. Thus it displays 'wrong' information,- seen by OP and me.
    #6
    Jim Nickerson
    User 452 _
    • Total Posts : 4101
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/03/27 06:28:32 (permalink)
    0
    I have found I can use a different config I call "debugxc..." and in it define a macro "__DEBUG" which is picked up by my
     #if defined(__DEBUG) // only in debug
    statements
     
     
    edit: fix typo
    #7
    rodims
    Super Member
    • Total Posts : 827
    • Reward points : 0
    • Joined: 2009/02/10 11:08:59
    • Location: 51.9627, 7.6262
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/03/27 06:50:23 (permalink)
    0
    moserI guess the described behavior is just the best, which the IDE can do.

    I agree for e.g. "Build for Debugging", since there is no (obvious) 'state' (or setting) for __DEBUG.
    Still simply selecting the older C30 compiler tool chain changes the behaviour to the opposite, i.e. __DEBUG then is not defined (for parsing).
     
    This seems to be more correct for me, since this at least allows me to define __DEBUG myself as preprocessor macro and use it in e.g. two different configurations for Debug and Release.  This is not easily possible with the behaviour with the XC16 (1.31) tool-chain.
     
    But it's not important for myself, I only have very few places with #ifdef __DEBUG
     
    JimI have found I can use a different config I call "debugxc..." and in it define a macro "__DEBUG"

    Yes, but since it is always defined, you would instead have to undefine it in the preprocessor macros. I think that is not possible, but did not investigate that.  (would probably require gcc -U option)
    #8
    moser
    Super Member
    • Total Posts : 259
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/03/27 06:54:23 (permalink)
    0
    rodims, you are both correct and wrong. __DEBUG is NOT defined by the command line. And __DEBUG IS defined by the command line. 
     
    If I press "Build for Debugging (Project <myproject>)" it definitely NOT in the command line - as you said: 
    "C:\Program Files (x86)\Microchip\xc32\v1.42\bin\xc32-gcc.exe" -g -x c -c -mprocessor=32MZ2048EFM144 [...]

    Therefore, graying out a #ifndef __DEBUG would be wrong.
     
    But if I press "Build for Debugging (Project <myproject>)" it definitely IS in the command line - in contrast to what you said:
    "C:\Program Files (x86)\Microchip\xc32\v1.42\bin\xc32-gcc.exe" -g -D__DEBUG -D__MPLAB_DEBUGGER_ICD3=1 -fframe-base-loclist -x c -c -mprocessor=32MZ2048EFM144 [...]

    Therefore, NOT graying out a #ifndef __DEBUG would be wrong.
     
    The IDE cannot guess which button you are going to press. No matter how it is doing it, it is always wrong for one case, and correct for the other case.
     
    It not clear whether __DEBUG must be defined or not defined ... until that moment, when you press one of the compile buttons. And since it is not clear before your button press, there is no "wrong" or "correct" display.
    post edited by moser - 2017/03/27 06:56:31
    #9
    moser
    Super Member
    • Total Posts : 259
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/03/27 07:03:35 (permalink)
    0
    rodims
    JimI have found I can use a different config I call "debugxc..." and in it define a macro "__DEBUG"

    Yes, but since it is always defined, you would instead have to undefine it in the preprocessor macros. I think that is not possible, but did not investigate that.  (would probably require gcc -U option)
    -U is supported by XC32 v1.42 and evaluated after all -D options.
     
    I believe the workaround with two configurations is probably the best, if the graying out of (non-)debug sections is too much annoying.
    #10
    NKurzman
    A Guy on the Net
    • Total Posts : 14827
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/03/27 12:38:12 (permalink)
    +1 (1)
    This shows the If Debug contition true either way in MPLABX:
    #ifdef __DEBUG
       PLIB_WDT_Disable(WDT_ID_0);
       #warning ("WDT Disabled")
    #else
       // Set up WDT id not in the debugger
      PLIB_WDT_Enable(WDT_ID_0);
      PLIB_WDT_TimerClear(WDT_ID_0);
    #endif
     
    Since MPLABX adds -g -D__DEBUG -D__MPLAB_DEBUGGER_REAL_ICE=1
    to the command line only If you are debugging, it works correctly.
     
    But apparently it does not define it for the Display Parser.
    So it is one more instance where the MPLabX Parser differs from the Compiler.
     
    If no one from Microchip responds, you can put in a support ticket if you want to report it.
     
    #11
    rodims
    Super Member
    • Total Posts : 827
    • Reward points : 0
    • Joined: 2009/02/10 11:08:59
    • Location: 51.9627, 7.6262
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/04/21 08:29:47 (permalink)
    +1 (1)
    rodimsNo idea, which setting or bug "virtually" defines the __DEBUG for the IDE (virtually = grayed out by IDE)

     
    This thread discussed the behaviour in MpLabX 3.55 (and likely some previous versions).
    I cannot do many cross tests, but directly comparing MpLabX 3.55 and 3.60 with the same project, the MpLabX parser now displays the grayed out code as expected (depending on  __DEBUG) . It means the __DEBUG is no more magically defined somewhere, and you get back the flexibility to #define your own __DEBUG (in your sources for static review).
     
    In 3.55 the following code would always show the __DEBUG path as enabled (active code), while the #else path is "grayed out".  Although the __DEBUG was not defined anywhere (from developers point of view).
     
     #ifdef __DEBUG
        dbgPuts("IDLE...\n");
      #else
        dbgPuts("SLEEP...\n");         
      #endif

     
    In 3.60 this has been fixed, the #else path is shown as enabled, if you do not #define __DEBUG on your own.
    Still it's possible to add your own #define __DEBUG somewhere, to gray out the code in the #else path.
    (and as it would be compiled for a compiler run for DEBUG mode. 
    #12
    Edzko
    New Member
    • Total Posts : 1
    • Reward points : 0
    • Joined: 2017/09/10 05:31:07
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/09/12 21:39:05 (permalink)
    0
    I've solved this problem by
    1) Adding a Pre-build script that creates a header file to set a custom define, if __DEBUG is defined
    2) Adding a Post-build script that overwrites this header to set the custom define, or to just include a comment, based on the content of the dist/[project]/debug and dist/[project]/production folders.
    3) include the header in the source code, and use the custom define instead of the __DEBUG
    PS; The Pre/Post-build scripts are called with the project name as the argument
    PreFixDbg.bat
    @ECHO OFF
    ECHO Processing project %1
    (ECHO #ifdef __DEBUG & ECHO #define __FIXDBG & ECHO #endif) > fixdbg.h
    FixDbg.bat
    @ECHO OFF
    ECHO Processing source code bootloader for %1
    REM sleep 2
    IF EXIST dist\%1\debug\memoryfile.xml (
    IF EXIST dist\%1\production\memoryfile.xml (
    CSCRIPT fixdbg.vbs %1
    ) ELSE (
    ECHO #define __FIXDBG > fixdbg.h
    )
    ) ELSE (
    ECHO // Production version > fixdbg.h
    )
    FixDbg.vbs
    Set objFS = CreateObject("Scripting.FileSystemObject")
    Set objArgs = WScript.Arguments
    Set objFile1 = objFS.GetFile("dist\"&objArgs(0)&"\debug\memoryfile.xml")
    Set objFile2 = objFS.GetFile("dist\"&objArgs(0)&"\production\memoryfile.xml")
    Set objFile = objFS.CreateTextFile("fixdbg.h",True)
    If objFile1.DateLastModified > objFile2.DateLastModified Then
        objFile.Write "#define __FIXDBG" & vbCrLf
    Else
        objFile.Write "// Production version" & vbCrLf
    End If
    objFile.Close
    #13
    jartim
    Bit basher
    • Total Posts : 21
    • Reward points : 0
    • Joined: 2017/07/07 00:28:33
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/09/14 09:02:18 (permalink)
    +2 (2)
    Unfortunately although you can define your own __DEBUG macro for the parser, the IDE actually creates another macro called _DEBUG (only 1 underscore), so the greyed-out code in the editor will still not be hidden to the compiler.
    "C:\Program Files (x86)\SourceBoost\xlaunch.exe" -d_DEBUG -t PIC12F635 -obj "build/Simulator/debug" -o "build/Simulator/debug/config.o" config.cpp -Oa -W2 -Werr -v -Su
    "C:\Program Files (x86)\SourceBoost\xlaunch.exe" -d_DEBUG -t PIC12F635 -obj "build/Simulator/debug" -o "build/Simulator/debug/init.o" init.cpp -Oa -W2 -Werr -v -Su
    "C:\Program Files (x86)\SourceBoost\xlaunch.exe" -d_DEBUG -t PIC12F635 -obj "build/Simulator/debug" -o "build/Simulator/debug/main.o" main.cpp -Oa -W2 -Werr -v -Su
    Admittedly I am using the SourceBoost compiler and that may be different to XC8 or the assembler, I'm not sure.  My point is though, the IDE will always just define the DEBUG (or _DEBUG, or __DEBUG) macro depending on which button you click to build your code.  Personally I think we would all be better off if MPLAB-X didn't try to be so clever and just let us define it for ourselves, when and where we needed it!
    #14
    jartim
    Bit basher
    • Total Posts : 21
    • Reward points : 0
    • Joined: 2017/07/07 00:28:33
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/09/20 03:23:39 (permalink)
    0
    I have since discovered that the greying out of code in the editor does work, but only if the #define and the #ifdef are in the same source file!  This is pretty useless for projects with more than one source file as it means most of your files won't show the greyed out sections greyed out at all.  It probably means that the built-in indexer doesn't work very well and doesn't scan the entire project when it should.
    #15
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 1332
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/09/20 05:44:34 (permalink)
    +1 (1)
    That is how it should be otherwise it would lead to a lot of compile errors.  Not knowing what order the compiler will compile the files.
     
    #ifdef x
    #include "a"
    #include "b"
    #else
    #include "c"
    #include "d"
    #endif
     

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #16
    jartim
    Bit basher
    • Total Posts : 21
    • Reward points : 0
    • Joined: 2017/07/07 00:28:33
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/09/29 02:21:26 (permalink)
    0
    Hmm, Eclipse and Visual Studio manage to do it right, why not MPLAB-X as well?
    #17
    moser
    Super Member
    • Total Posts : 259
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/09/29 03:51:58 (permalink)
    +2 (2)
    In Eclipse and Visual Studio "Debug" and "Release" are configurations, and you always have one selected. You have a drop down or a selection for that. Therefore, those always know,whether to highlight a #ifdef __DEBUG section or not.
     
    MPLAB X doesn't have that state, because it has a button for build debug and one for build release. It doesn't know which button you are going to press. And therefore doesn't know which section to highlight. This is not just a bug, its a problem of whole concept. Of course, introducing a switch which allows you to select, whether you want highlighting for debug or for release would be good. And also doing it in the same way, as the last pressed button, is a good way, which is what edzko is doing with the script.
     
     
    You can read about those generated macros in the MPLAB X IDE User's Guide, section 4.17.2 "Debug Macros Generated". And section 6.4.2 "Add a Duplicate Configuration" even tells you how to make your own debug configuration, which allows you to select what to highlight.
    #18
    KTrenholm
    Super Member
    • Total Posts : 207
    • Reward points : 0
    • Joined: 2012/08/08 14:04:23
    • Location: Connecticut, USA
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/09/29 11:06:55 (permalink)
    +2 (2)
    I've also fiddled with this and have started just keeping separate configurations (one for testing and one for release) and then just select the config from the dropdown in MPLAB X.  I define TESTING as a common macro in the XC global options of the config I want to use for debugging (as well as turning off optimizations, etc).   Unfortunately this also means you have to set these configurations up in this fashion every time you start a new project but it does work to do what you're describing.
    #19
    jartim
    Bit basher
    • Total Posts : 21
    • Reward points : 0
    • Joined: 2017/07/07 00:28:33
    • Location: 0
    • Status: offline
    Re: Ifndef __DEBUG greying out wrong code 2017/10/04 03:54:55 (permalink)
    0
    moser
    In Eclipse and Visual Studio "Debug" and "Release" are configurations, and you always have one selected. You have a drop down or a selection for that. Therefore, those always know,whether to highlight a #ifdef __DEBUG section or not.
     

     
     
    But MPLAB-X supports configurations as well, doesn't it? In fact that's exactly how we used to do it in earlier versions of MPLAB - you could specify one configuration for debug and one for release and define a compile-time __DEBUG macro in the configuration.  The configurations now are more complicated and cover more options, but essentially they are the same as earlier versions.  
    The main problem, IMO, is that the IDE is trying to be too clever by having different release and debug build options.
    #20
    Jump to:
    © 2017 APG vNext Commercial Version 4.5