cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

digbug
Journeyman III

Does CodeXl step into a Kernel built by clBuildProgramWithBinary?

I can step into the Kernel built by clBuildProgramWithSource, which is good.

However, the clBuildProgramWithSource took me 2+ mins (with 100+ Kernels) to wait for the compilation finish, which is bad since I need debug the Kernel.

So I buid the program using clBuildProgramWithBinary.

Then CodeXl tell me i can NOT get the source code so i can NOT step into the kernel any more.

So, the question is:

Is there anyway to step into the Kernel built by clBuildProgramWithBinay?

0 Likes
1 Solution

Hi digbug,

There are several layers of answers to your question:

1. Indeed, CodeXL only currently supports debugging with clBuildProgramWithSource

2. This is required, since to allow debugging of the kernel, CodeXL changes the build flags in clBuildProgram, to make the AMD compiler add debug information, etc. Thus - even if debugging such program was possible, a program that you originally built outside CodeXL's debug mode would not be debuggable.

3. IIRC, currently, if you saved the binary generated by clBuildProgramWithSource inside CodeXL (i.e. the binary with the debug information), and use clCreateProgramWithBinaries - there is no hard lock on debugging it - you will simply not have source code available (the call stack view will appear correctly, with function names and line numbers - but the source code will not be available).

4. Allowing debugging of programs created with clCreateProgramWithBinaries is definitely on our feature wishlist, and we have several possible solutions (save the sources with the debug information and read them back, allow the user to link a binary program with sources, etc) - but it is not yet included in the upcoming release of CodeXL.

5. As a workaround for your issue (and as a general better practice), I would suggest that at least for debugging purposes, you separate the program to smaller programs containing fewer kernels (we did the same with our own Teapot sample), and put any common code in header files (OpenCL allows the #include directive).

Hope this helps,

View solution in original post

0 Likes
2 Replies

Hi digbug,

There are several layers of answers to your question:

1. Indeed, CodeXL only currently supports debugging with clBuildProgramWithSource

2. This is required, since to allow debugging of the kernel, CodeXL changes the build flags in clBuildProgram, to make the AMD compiler add debug information, etc. Thus - even if debugging such program was possible, a program that you originally built outside CodeXL's debug mode would not be debuggable.

3. IIRC, currently, if you saved the binary generated by clBuildProgramWithSource inside CodeXL (i.e. the binary with the debug information), and use clCreateProgramWithBinaries - there is no hard lock on debugging it - you will simply not have source code available (the call stack view will appear correctly, with function names and line numbers - but the source code will not be available).

4. Allowing debugging of programs created with clCreateProgramWithBinaries is definitely on our feature wishlist, and we have several possible solutions (save the sources with the debug information and read them back, allow the user to link a binary program with sources, etc) - but it is not yet included in the upcoming release of CodeXL.

5. As a workaround for your issue (and as a general better practice), I would suggest that at least for debugging purposes, you separate the program to smaller programs containing fewer kernels (we did the same with our own Teapot sample), and put any common code in header files (OpenCL allows the #include directive).

Hope this helps,

0 Likes

To Elaborate on #3:

When I say "If you saved the binary generated ... inside CodeXL", it means this:

1. Create an application with the following call sequence:

1A. clCreateProgramWithSource

1B. clBuildProgram

1C. clGetProgramInfo(CL_PROGRAM_BINARIES)

1D. Save the output from 1C to memory / a file / etc.

2. Run this application within CodeXL

3. Take the output from 1D as it is ran inside CodeXL (2)and feed it to clCreateProgramWithBinaries

4. Take the output from 1D as it is ran without CodeXL and feed it to clCreateProgramWithBinaries.

The program created in step #3 should be (IIRC) debuggable inside CodeXL (though still no source code). The program created in step #4 will not be.

Hope this is clearer,

0 Likes