I am working with OpenCL and I have many problems with the pointers(segmentation violation). How I can debug the kernel code for GPU to see the memory where I am putting my atributes and see my mistakes??
There were/are some GPU debugging tools, but another method is to use the Intel CPU driver and debug using a CPU debugger. Here's an article from Intel on how to do it:
https://software.intel.com/en-us/node/539339
Alternatively, since it's C99, you can just move the kernel code into a regular C/C++ program and get the logic working there first, and then move it to a kernel.
Related
I wanna know if normal practice of setting the breakpoints, step-in & step-out works same for the code which reside on ROM also. Do we have to do something extra for ROM debugging.
It will depend largely on the processor an the debug hardware you use. Many microcontrollers include on-chip debug hardware that includes hardware breakpoints that are essentially program-counter comparators. Other facilities may be supported such as data access break-points and instruction trace - essentially an on-chip in-circuit emulator (ICE).
Hardware breakpoints are a necessarily limited resource; for example ARM7 devices have just two while ARM Cortex-M3/4 are endowed with eight.
Either way, to utilise on-chip debug you require suitable debugger hardware (often via JTAG, or a vendor proprietary interface) to interface the target to the host debugger software.
For chips without on-chip debug, you typically use an in-circuit emulator. This is debug hardware that connects to the target board in place of the processor and can be controlled directly by the host debug software. The emulator hardware executes instructions identically to the actual processor but can be halted and stepped and have breakpoints set. Essentially the ICE works like a special version of the target processor with debug support. A true ICE is uncommon on modern processors since on-chip debug capabilities are almost ubiquitous even on small devices such as PIC and AVR, however some external debug hardware can support features not available on on-chip debug. For example Segger's J-Link supports unlimited break-points on ARM7 and Cortex-M3/4.
Is there any memory debugger for linux kernel?
We have issues with "NULL pointer dereference" kernel oops among other crashes on android/linux arm based hardware.
Thanks
Modern kernels contain a great deal of built-in diagnostic tools (those are available in "Kernel hacking" sub-menu of the kernel source configuration tool). However, on embedded targets one has also an option of using gdb with a good jtag debugger, such as Abatron BDI series (this will, of course, allow for the most precise diagnostics, including diagnostics of interrupt related problems).
In the absence of hardware debugger, the following options can be quite handy to detect memory leaks (don't forget to compile the kernel with "Compile the kernel with debug info" and "Compile the kernel with frame pointers" set):
Kernel memory leak detector - useful in catching kmalloc/kfree errors.
KGDB (with suboptions) - this will enable a built-in gdb server inside the kernel, which can be accessed from a gdb front-end over a serial port. There's also a KGDB_KDB option to do the same manually (by omitting the gdb front end and using a human manageable protocol).
kmemcheck - requires the least of human interaction and the most machine resources, but can be handy in doing initial memory related problem analysis.
There are plenty of other diagnostics options, useful with more specific classes of problems. Most of them are reasonably documented both with kernel configuration tool snippets as well as with separate documents in Documentation/ sub-directory of the source (+ various online publications).
I'm using the Intel SDK for OpenCL with an Intel HD Graphics 4000 GPU to successfully run an OpenCL program. I've made sure to link against the Intel OpenCL libraries since I also have Nvidia libraries installed.
However, putting a printf() call in the kernel gives the OpenCL compiler error
error: implicit declaration of function 'printf' is not allowed in OpenCL
Also, I've enabled OpenCL kernel debugging in the Visual Studio 2012 plugin, and passed the following options to clBuildProgram:
"-g -s C:\\Path\\to\\my\\program.cl"
However, kernel breakpoints are skipped. Hovering over the breakpoint gives the message:
The breakpoint will not currently be hit. No symbols have been loaded for this document.
My kernels are in a separate .cl file, and I'm setting the breakpoints the way I would for C/C++ code. Is this the correct way to set breakpoints using the Intel SDK for OpenCL debugger?
Why are printf() calls and breakpoints not working with the Intel SDK for OpenCL?
THe function printf() was introduced in the OCL version 1.2. Intel released this version not that long time ago. I'd bet that you still have the 1.1 version.
Regarding the debugger I almost never used it but based on this document the path is supposed to be given like that:
"-g -s \"C:\\Path\\to\\my\\program.cl\""
You are also supposed to choose which thread you wanna debug.
Is there a way to step into OpenCL kernel code running on a CPU device (MAC)?
I can use printfs but I would like to step into kernel code.
I believe not. The ability is not mentioned in the "Debugging" section of the OpenCL for OSX documentation (and PDF).
I'm running a CUDA library that I need to debug for memory problems and other issues. But when I attach cuda-gdb to the process I get the error
error: All CUDA devices are used for X11 and cannot be used while debugging.
I understand the error, but there has to be a way that I can debug the issues. Since I only have 1 GPU, it really isn't practical to turn off X11.
On non Nvidia hardware I thought there was a way to emulate a cuda gpu. could this be setup for debugging even though I have an NVIDIA gpu?
First of all, as you are using Linux you're in a lucky position as you can kill X pretty easily just for the time of debugging.
However, if you really want to stick to running X while debugging you are out of luck, as this is not possible for a very good reason: the display driver has a protection mechanism called watchdog timer which is enabled when the GPU in use also drives a display. The watchdog timer interrupts any kernel that runs for longer AFAIR 5s. This is intended to prevent GPU lockups.
Alternatively, you could try using ocelot, but I am not sure how good are the debugging features it provides.