Recent

Author Topic: [Solv] Blue debug points tracking (via a custom compil. directive) the dead code  (Read 2775 times)

devEric69

  • Hero Member
  • *****
  • Posts: 648
Hello,

I've a compiler and debugger problem. I switch a personnal compilation directive...:

Code: Pascal  [Select][+][-]
  1. {$If defined(DebugOnlyCompTLAZAUTOUPDATE__iciSeulement)}
  2. ...\... // I want to pass here,
  3. {$Else}
  4. ...\... // but the debugger always tracks this part of code??!
  5. {$EndIf}

...to true in my code (through the project's options, checking it): the "live" code branch is correctly illuminated, and the dead code branch is correctly turned off (greyed - through the Lazarus'IDE colors parameters - in the screenshot). The problem is that the blue debugging dots go into the dead code branch, and that the debugger also traces at runtime the dead code branch. In short, it's dead code that's being executed??!

AMHO, this isn't normal: the runtime debugging information seems not correct, hence my question: how to explain this, i.e. how to make sure to trace the living code, to pass in the living code branch?

edit 1: I've the same problem with this statement:
Code: Pascal  [Select][+][-]
  1. {$IFDEF DebugOnlyCompTLAZAUTOUPDATE__iciSeulement}
  2. ...\... // I want to pass here,
  3. {$ELSE}
  4. ...\... // but the debugger always tracks this part of code??!
  5. {$ENDIF}
  6.  

edit 2: I've the same problem with this statement (all uppercase):
Code: Pascal  [Select][+][-]
  1. {$IfDEF DEBUG_COMP_TLAZAUTOUPDATE_ICI_SEULEMENT}
  2. ...\... // I want to pass here,
  3. {$ELSE}
  4. ...\... // but the debugger always tracks this part of code??!
  5. {$ENDIF}


Regards.
« Last Edit: September 17, 2021, 07:15:19 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Assuming (the obvious...) that the code got recompiled after the $define was changed... And that the code was not edited after it got compiled...

This is a compiler problem.
The compiler puts in a map of address to line-number.
The debugger could not get the line number unless the compiler put it in there.

You can double check the line num in the debug info, using objdump

If that is external debug info, make sure it is not an old file. (should fail, since likely it's checksum would have changed, but....)

« Last Edit: September 17, 2021, 05:17:56 pm by Martin_fr »

ccrause

  • Hero Member
  • *****
  • Posts: 843
@devEric69: Did you rebuild your project after changing your define?  The compiler will not know it has to recompile the affected code if the only change is a change in a user define.

A low tech test (as opposed to Martin's suggestion to check with objdump) to see which branch of the $if is actually compiled is to add an informative writeln or ShowMessage statement in each branch. Then compare the message displayed against the code highlighted by the debugger.

devEric69

  • Hero Member
  • *****
  • Posts: 648
Hello @Martin_fr, hello @ccrause: thank you for your answers. I've found that I didn't very well quite understood the "Custom options" and "Additions and overrides" settings.

I thought that when I added a new "Custom options" - said dFoo - checked in a build mode - said build_mode_1 - it automatically added and checked the new dFoo identity inside the canonical base of the build directives and inside the generation of the correct selected build mode (at the time of its check). In fact: no; I also have to manually complete the build modes creation matrix by adding the new said compiler directive in its canonical base, and then I always have to check in which build mode it's injected only (that's all; I need to better read the interfaces :D ).



« Last Edit: September 17, 2021, 07:47:58 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

 

TinyPortal © 2005-2018