cvs commit: modperl-docs/src/docs/2.0/devel/debug/code .debug-inline

[st...@apache.org]

stas        2003/05/27 23:43:02

  Modified:    src/docs/2.0/devel/debug c.pod
  Added:       src/docs/2.0/devel/debug/code .debug-inline
  Log:
  add a gdb script to debug Inline.pm-generated so's
  
  Revision  Changes    Path
  1.12      +11 -0     modperl-docs/src/docs/2.0/devel/debug/c.pod
  
  Index: c.pod
  ===================================================================
  RCS file: /home/cvs/modperl-docs/src/docs/2.0/devel/debug/c.pod,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- c.pod	22 Apr 2003 06:26:21 -0000	1.11
  +++ c.pod	28 May 2003 06:43:02 -0000	1.12
  @@ -269,6 +269,17 @@
   When I<filter/api> test is running it calls
   mpxs_Apache__Filter_print() which is when the breakpoint is reached.
   
  +=item * Debugging code in shared objects created by C<Inline.pm>
  +
  +This is not strictly related to mod_perl, but sometimes when trying to
  +reproduce a problem (e.g. for a p5p bug-report) outside mod_perl, the
  +code has to be written in C. And in certain cases, Inline can be just
  +the right tool to do it quickly. However if you want to interactively
  +debug the library that it creates, it might get tricky. So similar to
  +the previous sections, here is a gdb F<code/.debug-inline> startup
  +script that will save you a lot of time. All the details and a sample
  +perl script are inside the gdb script.
  +
   =back
   
   
  
  
  
  1.1                  modperl-docs/src/docs/2.0/devel/debug/code/.debug-inline
  
  Index: .debug-inline
  ===================================================================
  
  # save this file as .debug and execute this as:
  # gdb -command=.debug
  # or if you prefer gui
  # ddd -command=.debug
  #
  # NOTE: Adjust the path to the perl executable
  # also this perl should be built with debug enabled
  file /usr/bin/perl
  
  # If you need to debug with gdb a live script and not a library, you
  # are going to have a hard time to set any breakpoint in the C code.
  # the workaround is force Inline to compile and load .so, by putting
  # all the code in the BEGIN {} block and call Inline->init from there.
  #
  # you also need to prevent from Inline deleting autogenerated .xs so
  # you can step through the C source code, and of course you need to
  # add '-g' so .so won't be stripped of debug info
  #
  # here is a sample perl script that can be used with this gdb script
  #
  # test.pl
  # #-----#
  # use strict;
  # use warnings;
  #
  # BEGIN {
  # use Inline Config =>
  #     #FORCE_BUILD => 1,
  #     CLEAN_AFTER_BUILD => 0;
  #
  # use Inline C => Config =>
  #     OPTIMIZE => '-g';
  #
  # use Inline C => <<END;
  # void my_bp() {
  #     dTHX;
  #     Perl_warn(aTHX_ "starting debug\n");
  # }
  # END
  #
  # Inline->init;
  #
  # }
  #
  # my_bp();
  
  tb main
  # NOTE: adjust the name of the script that you run
  run test.pl
  
  # when Perl_runops_debug breakpoint is hit Inline will already load
  # the autogenerated .so, so we can set the bp in it (that's only if
  # you have run 'Inline->init' inside the BEGIN {} block
  
  b S_run_body
  continue
  b Perl_runops_debug
  continue
  
  # here you set your breakpoints
  b my_bp
  continue
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-cvs-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-cvs-help@perl.apache.org