atom feed7 messages in org.perl.perl-xsRe: How to debug XS Module
FromSent OnAttachments
Peter J JonesJan 5, 1999 1:06 pm 
Buzz MoschettiJan 5, 1999 2:06 pm 
David DyckJan 5, 1999 2:27 pm 
Stephen ZanderJan 6, 1999 3:44 pm 
Eric MalandJan 6, 1999 9:58 pm.tgz
David DyckJan 7, 1999 10:30 am.tgz
Nick Ing-SimmonsJan 7, 1999 11:58 am.debug
Subject:Re: How to debug XS Module
From:Eric Maland (
Date:Jan 6, 1999 9:58:47 pm
Foo.tgz - 4k

It seems like real overkill, to me, to build a static version of perl with debugging symbols just to debug one module. maybe i'm just lazy.

The approach I take to debugging XS modules (and this is entirely home-brewed, since I've found virtually zero useful information on the subject) is this: * Build your module, test it, watch it segfault or whatever. * Once this has occurred, rebuild it with debugging symbols and don't strip symbols from the module (MakeMaker defaults to using ld -s). * Load perl into gdb, and get into the perl debugger. From there, load your module (use DynaLoader, add the module path to your @INC and 'use' it, do it from the command line, whatever). Now we're "meta-debugging". * Execute your perl/XS code, and watch it die. Nicely. In gdb. Where you can debug it.

You also have the option of loading the symbols from the shared library in gdb, and from there you can set breakpoints, which tends to be useful. I've never had a need for a staticly linked module just to debug it(!). Nor have I ever required a version of perl with debugging symbols included. I'm glad. Who has time for that? Maybe if you're debugging perl that would be useful, but aside from that I see no real benefit (maybe i'm ignorant of the limitations of other platforms, though, some on which I know you would have to statically link, so please don't flame me on that).

I've attached a dinky module that just calls one XS function that strcpy()'s into a NULL pointer, and included in it a 'debuglog' file that shows how I approach debugging this type of problem in XS modules (just a screen snapshot of my debugging session, with some minor comments at the top). This seems to work 9 times out of 10, for me. Your results may vary. I suspect the platform you're working on and your compiler and linker may be quite different from mine so out-of-the-box my method may not work for you - in fact, it probably won't. But if you get the general idea, it should be easy to tweak to work on your platform.

Hope this helps.