From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

With CVI2013 breakpoints work differently

Solved!
Go to solution

In the past, I used to insert lines 'doing nothing' but allowing me to set a breakpoint. Now, with CVI2013, the following does not work anymore:

 

if ( expression )

{

// something

}

else

{

;    <- putting a breakpoint here is useless: the breakpoint is ignored

}

 

The workaround is to have something like

 

if ( expression )

{

// something

}

else

{

Delay (0.1);    <- putting a breakpoint works

}

 

Could it be that clang is 'optimizing code' even in debug mode...?

 

Also, setting or removing a breakpoint causes the file being recompiled - this slows down debugging enormously Smiley Frustrated

 

0 Kudos
Message 1 of 6
(4,136 Views)

Hi Wolfgang,

 

you're right. The compiler is optimizing the code even in debug mode. Maybe you could try to change the compiler optimization level to solve your problem.

 

What Do The LabWindows/CVI Compiler Optimization Levels Mean?

http://digital.ni.com/public.nsf/allkb/8A38D87DDA143CBC86257BB90077C217

 

Regards,

Lars

0 Kudos
Message 2 of 6
(4,117 Views)

Hi Lars,

 

thanks for the input! I did play with the optimizations before (of course...Smiley Wink) and did not see a difference, not even in compilation time, unfortunately.

 

What I did notice is that the breakpoint may be shifted - and this is in accordance with the help saying that LabWindows/CVI moves the breakpoint to the next line that contains executable code.

 

Is there any good reason why the compiler should optimize code in debug mode even if release mode is set to no optimizations? The Build Options panel seems to imply no optimizations..., see below

 

 

build.png

0 Kudos
Message 3 of 6
(4,109 Views)
Solution
Accepted by topic author Wolfgang

Hello Wolfgang,

 

The compiler is "optimizing" code in debug configurations in the sense that it's not generating any code for an empty statement (a single semicolon). It's not doing any other kinds of optimizations. I have filed bug report # 423474 for the issue, because as you point out it can be quite useful to be able to set a breakpoint on those empty statements.

 

I cannot reproduce your second problem. I can set and remove breakpoints during a debugging session as in CVI 2012. The file is not recompiled as a result and the debugging session is not restarted or aborted. I'm probably missing something. Can you post step-by-step instructions to reproduce the problem?

 

(FYI: When you start debugging, CVI always checks if anything in your project has to be rebuilt and the Build Output window appears. But this doesn't mean that CVI is actually rebuilding anything. It's just our way of saying "Just checking if the project is still up to date. And it is. Move along.")

 

Thanks,

 

Peter

Message 4 of 6
(4,086 Views)

Hello Peter,

 

Thank you for the explanation of 'optimization'.

 

Personally I would not have called this behavior a bug - it's different than before (and somewhat less convenient) and thus should have been mentioned in the Release Notes, that's all. But I'll be glad to see this optimization removed!

 

Concerning the second issue - you are right, my observation was somewhat defocused, I have corrected it here

0 Kudos
Message 5 of 6
(4,079 Views)

CVI2013 SP2 now permits setting a breakpoint on lines with empty statements Smiley Happy

0 Kudos
Message 6 of 6
(3,299 Views)