I would echo the comments you already have about the debugger flag. Another thing I have found with XS is that I have had trouble getting perl to run in the debugger (admittedly this is mostly when I am messing with interrupts and with modules linked to dynamic libraries). A trick that I have found usefull is to temporarily insert an infinite loop at the start of my C code:

int temp_val;
temp_val = 100;

/* An infinite loop that usually won't be optimised away */
while(temp_val > 0)
  {
    temp_val--;
    if(temp_val < 50)
        temp_val = 100;
  }
[download]

Then start up the perl script, it will go into the infinite loop. Use

to get its process number. Start gdb with

And get out of the infinite loop with

Now you have a gdb session with all the correct libraries loaded stopped at the start of your routine.

Just some improvement suggestions to an otherwise excellent method:
1. The use of volatile decalaration for the loop guard will make the loop much more terse.
2. Sticking in an odd call to sleep(1); will make your instrumented system much easier on your the rest of your OS.
Cheers, ---Lars

Cool tip. We do a lot of java-stuff at work (sadly, little Perl) and we have never been able to debug native code and usually resort to fprintf, or writing a command line tool to use the libraries as opposed to Java over JNI. This might help! Just thinking outloud here, but what happens with the Inline modules? I've never used them (I need to!), but I am guessing using Inline ::C to call into a module would pretty much keep debugging the same way? Does Inline::C complicate the Perl debugger?

Thanks hawtin.
Thanks all the monks who have given valuable pointers. Now what I have done, I first put an infinite loop in .c file and build it with -g and without -O option. Started perl script and now I can debug with gdb after attaching PID.
Thanks again.
-Pijush