Lazarus

Using the Lazarus IDE => Debugger => Topic started by: devEric69 on September 17, 2021, 04:51:06 pm

Title: [Solv] Blue debug points tracking (via a custom compil. directive) the dead code
Post by: devEric69 on September 17, 2021, 04:51:06 pm

Hello,

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

Code: Pascal [Select][+]

{$If defined(DebugOnlyCompTLAZAUTOUPDATE__iciSeulement)}
...\... // I want to pass here,
{$Else}
...\... // but the debugger always tracks this part of code??!
{$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][+]

{$IFDEF DebugOnlyCompTLAZAUTOUPDATE__iciSeulement}
...\... // I want to pass here,
{$ELSE}
...\... // but the debugger always tracks this part of code??!
{$ENDIF} 
 

edit 2: I've the same problem with this statement (all uppercase):

Code: Pascal [Select][+]

{$IfDEF DEBUG_COMP_TLAZAUTOUPDATE_ICI_SEULEMENT}
...\... // I want to pass here,
{$ELSE}
...\... // but the debugger always tracks this part of code??!
{$ENDIF}

Regards.

Title: Re: (Err?) Blue debug points tracking (via a custom compil. directive) the dead code
Post by: Martin_fr on September 17, 2021, 05:16:25 pm

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....)

Title: Re: (Err?) Blue debug points tracking (via a custom compil. directive) the dead code
Post by: ccrause on September 17, 2021, 06:06:14 pm

@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.

Title: Re: (Err?) Blue debug points tracking (via a custom compil. directive) the dead code
Post by: devEric69 on September 17, 2021, 07:13:23 pm

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 ).