Code Builder missing VS breakpoints

[PCox]

I'm working with code builder. I've been running happily for six months with the 2014 ocl applications SDK under VS2010. I thought I knew all the tricks to ensure kernel breakpoints were hit, but one (large) new project consistently fails to hit breakpoints. I figured I can't go to forums with an old version, so I tried installing INDE with the restricted options for just a Code Builder installation, but that just stripped out my old VS2010 code builder extensions. So I took a deep breath and installed the whole INDE, with the same results (later I noticed that INDE did install code builder extensions for VS2013: does it not work for 2010 anymore???).

Anyway sadly all in vain: still no breakpoints getting hit. Code builder has "Enable opencl kernel debugging' set, and the "Enable OpenCL API debugger" is also set, for what its worth. Work items are set for 0,0,0. Debugging is on the local machine. Kernels were built with the -g -s <source> option (no other options), and the source is certainly the right one. No offsets. Device is my local i7-4770. Windows 7 Enterprise SP1 64 bit. Latest Iris and HD graphics driver (15.36.19.64.4170). Haven't checked the OpenCL runtime, but presume that was updated with INDE..?

I have a one thread dummy kernel that just prints its local thread:

__kernel void debugTest()
{
    printf("%d\n",get_local_id(0));
}

The kernel dutifully runs and prints. It just ignores the breakpoint and completes normally.

Please am I missing anything?? Getting stressed.

[PCox]

.
 

[Oded_P_Intel]

Hi Philip,

Thank you for bringing this to our attention.

As you probably know the debugger supports only the CPU device, please check that all the kernels you’re trying to debug are running on CPU only.

If you are running on CPU, we can try and locate the problem with the debugger logger.

In order to activate the logger, set these environment variables and restart VS:

• INTEL_OCL_DBG_LOG 1
• INTEL_OCL_DBG_LOG_FILE <full_path_to_log_file>

Run your application (with the debugger set) and send us the log file for analysis.

If it is possible, you can also send us the project you’re working on and we can try to check why the debugger doesn’t work on it.

Best Regards,

Oded

[PCox]

Hi Oded,

    Thanks for your timely response. Yes the target device is my local haswell CPU:

OpenCL device "Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz" on platform "Intel(R) OpenCL"

I've attached the log as requested. Sending source is harder for the usual corporate reasons, but I'll try and put together a safe mini project with the basics.

     Regards,

               phil

[PCox]

Hi Oded,

     Update on the update:

I had a .cl file which included a .clh file in the same directory.

Building without the –I option  (only –g –s) works and sees breakpoints OK: apparently the builder knows to look in the local directory for the .clh file.

I had wrongly assumed that the –I option was necessary to find that .clh file, and so added a relative path in for -I.

However I defined the wrong directory in that relative path, to a place where there was no .clh file.

Oddly everything still built and worked, however the debug part of the build apparently gets confused when it can’t find the .clh file, and turns off breakpoints. Once I’d corrected the relative path of the –I, everything sprang to life.

So what I learnt over the last two days (at least for intel opencl) :  

• OpenCL Header files in the same directory as the .cl file seem to be found OK by the builder without an –I option, and “-g –s” breakpoints all work OK.
• Non local header files need a –I option to the builder, which can be relative to the run location (unlike the –g – s directories, which are absolute)
• If the –I option doesn’t actually contain the location to the header file, but the header is in the same directory as the source .cl, all will build, but breakpoints are ignored. It would be nice to have the builder complain, but it doesn’t seem to happen.
• In preference. add header files at the clCreateProgramWithSource stage.

     One more thing: Do you know why INDE should have stripped out my VS2010 code builder extension, and not replaced it? Although VS2013 is fine, I have a lot of code still under vs2010, and really don't want to strip out the INDE and go back to the vs2014 openCL SDK. Thanks very much.

                           phil