NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
about I/O disciplines and I should retire to the Tassili-in-Aijer
mountains in Sahara as a camel herder :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Used it for debugging C (Score:1)
For Perl I prefer the '-d' debugging.
Are you adding debugging of XS modules?
If so I have a neat trick to debug using gdb that I learned from muppet on the perl-xs list.
I haven't tried it with ddd, I should test it someday.
Re: (Score:2)
Re:Used it for debugging C (Score:1)
#################################################
set the env var PASTHRU_INC when compiling your extension:
$ # turn on debugging symbols, turn off optimization (to
$ # prevent out-of-order execution that makes debugging
$ # rather confusing)
$ export PASTHRU_INC='-Wall -g -O0'
then you can run your program in gdb and be taken to the exactly right
spot when it crashes. you can inspect all of the values to find out
what happened.
some versions of gdb don't get things right when you try to set a
breakpoint in a module that isn't loaded yet, and since xs modules are
dynamic objects then you run into this a lot. i get around this by
running the perl debugger inside gdb.
$ gdb perl
(gdb) set args -d mycoolscript.pl
(gdb) run
DB # break here to get back to gdb
DB ^C
(gdb) # set the breakpoint where you want... C function...
(gdb) break gtk_main
(gdb) # or the xsub
(gdb) break XS_Gtk2_main
(gdb) # go back to perl
(gdb) continue
DB # carry on
DB c
Breakpoint 1, XS_Gtk2_main (my_perl=0x800200, cv=0x8c1434) at
xs/Gtk2.c:381
381 dXSARGS;
(gdb)
Reply to This
Parent