Cuda-gdb problem Cuda-gdb don't show symbols in device funcs


I’m debugging my program with cuda-gdb 2.2 and Cuda 2.2 drivers under linux 64 bits.

When i try to print a variable into a global function all goes well.

But when i try to print any variable into a device function, cuda-gdb always tell me: “No symbol “var name” in current context”

Is a bug? a non implemented feature? i’m forgetting something?

Actually i’m compiling with nvcc -g -G options and linking with nvcc with the same params.

I’ve searched through the forums but i don’t find any response about this.

Thanks in advance! ^_^

It sounds like a bug, but please provide a minimal code sample and post your gdb usage plz :)

Ntch, i’m trying to make a simple program but with a simple example it works :thumbsdown:

I’m currently have the cuda code into a shared library. The .cu file is compiled with -g -G --compiler-options = ‘-fPIC’, the rest of .cpp files with g++, then all of them are linked with nvcc -g -G --compiler-options = ‘-fPIC’ -shared.

For example in this piece of code:

[codebox]global void gpu_kernel(int array_width,int array_height )


int block_offset_cols = __mul24(blockIdx.x, blockDim.x);

    int block_offset_rows = __mul24(blockIdx.y, blockDim.y);

int array_start = block_offset_rows * array_width + block_offset_cols;

int me = array_start + __mul24(array_width, threadIdx.y) + threadIdx.x;



Breakpoint 2, gpu_kernel () at

246 int block_offset_cols = __mul24(blockIdx.x, blockDim.x);

Current language: auto; currently c++

… a few nexts to achieve the bottom …

(cuda-gdb) print block_offset_cols

$1 = 0

(cuda-gdb) print me

$2 = 0

(cuda-gdb) print array_start

$3 = 0

(cuda-gdb) print array_width

$4 = 2

(cuda-gdb) print array_height

$5 = 2

(cuda-gdb) print blockIdx

$6 = {x = 0, y = 0}

(cuda-gdb) print threadIdx

$7 = {x = 0, y = 0, z = 0}



All goes well, but, when i’m try to put a breakpoint in the device func that is in the same library (i try to put it when the shared library is already loaded)

[codebox]device bool device_kernel(float *pmin, float *pmax)


float vt0[3],vt1[3];

float t0,t1;

return true;


codebox break device_kernel

Function “device_kernel” not defined.

Make breakpoint pending on future shared library load? (y or [n]) n[/codebox]

Ntch, the library is already loaded! (the global and device funcs are in the same library)

With next, next, next, next… i arrive to device_kernel… time to see vars!!

codebox print vt0

No symbol “vt0” in current context.

(cuda-gdb) print vt1

No symbol “vt1” in current context.

(cuda-gdb) print t0

No symbol “t0” in current context.

(cuda-gdb) print t1

No symbol “t1” in current context.


But the params are visible!

codebox print pmin

$1 = (float * const @global) 0x16157b50

(cuda-gdb) print *pmin

$2 = -0.104707092

(cuda-gdb) print pmax[0]

$3 = 0.0710269064

(cuda-gdb) print pmax[1]

$4 = 0.197344124[/codebox]

Any ideas?

Thanks :thumbup:

Edit: Another thing, for developers. When you compile without -G option, run cuda-gdb, and try to put a breakpoint into a file that is part of a library but it isn’t in your current folder, you get a beautiful Segmentation fault :haha:

Edit2: More info, i’m using centos linux 64 bits, g++ 4.1.2 20080704 (Red Hat 4.1.2-44), Tesla C1060

I don’t think I can be of any help unfortunately.

Post a bug report while you are waiting (that is, run and attach the generated file) and hope to get a reply from someone who knows more.

It may not be a bug! The device function you have posted does nothing on the data you declared inside. Even if the compiler is set to optimization level 0 it will not insert unused variables in your code that implies that you cannot see them while debugging. I assume that the code you posted was just a sample to check the feature out and not a way to declare variables into a kernel for external use(sorry I didn’t look too well at the code you posted). Try and add or compare the two vars and return the comparision value (something like return t0 == t1) and try again.
Sorry for being so late… :(

I actually think this is a bug I already reported that should be fixed in the next release.