[Rcpp-devel] R.e. Debugging Rcpp packages with GDB

[Douglas Bates]

On Tue, Jan 18, 2011 at 6:19 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
> On 18 January 2011 at 15:52, Christian Gunning wrote:
> | On Tue, Jan 18, 2011 at 2:46 PM,
> | <rcpp-devel-request at lists.r-forge.r-project.org> wrote:
> | >
> | > Can people share any tricks they use to debug Rcpp packages? For example, can I "print" variables in a format that's a bit more high-level, like something that I would get if I sent them to "cout"?
> | >
> |
> | It's not very sophisticated, but I find that much of the time adding
> | Rf_PrintValue(xx) calls to code gives me as much info as I need.  If
> | it's a non-SEXP object like int, then Rf_PrintValue(wrap(my_int)).
> |
> | > If that's not entirely obvious from my question, I am not a GDB expert. :-) Basically, my workflow is: "attach to the R process", "set a breakpoint at the function entry point", "single-step and print variable values". I have used watches and conditional breakpoints in GUI debuggers, but not (yet) in gdb. Are there any Rcpp-specific gotchas to using those features with GDB?
> |
> | I have 2 related "simple questions" after reading through Chapters 1
> | and 4 of "Writing R Extensions":
> |
> | My build/test chain is:
> |
> | R CMD INSTALL mypackage
> | R --vanilla --debugger gdb
> | run
> | require(mypackage)
> | <test in R>
> | quit()
> | <edit code>
> | R CMD INSTALL mypackage
> | run
> | require(mypackage) ## reload package with edits
> | <lather, rinse, repeat>
> |
> | 1)  Is there a "best" way to reload the shared library after
> | rebuilding it? dyn.unload() and dyn.load()?
>
> I am partial to littler. Eg sometimes I just do
>
>  $ R CMD INSTALL foo && r -lfoo -e'someExpressionIWantToTest()'
>
> Because the 'r' (littler) starts fresh sessions I do not need to worry about
> unload.   In other cases I use inline -- it depends.
>
> | 2) Is there a simple way to include debugging symbols/keep values from
> | getting optimized out when building with Rcpp?
>
> You could always include -g and then strip what you don't need -- which is
> what Debian and Ubuntu do to give you the *-dbg packages.
>
> R sits on top of Makefile logic, and make is pretty powerful language.  You
> can (literally) do just about anything....   Setting CFGLAGS / CXXFLAGS or
> their PKG_* variants is probably easiest.

Or create a file $HOME/.R/Makevars and define CXXFLAGS and CFLAGS in
there.  I have the following contents

CFLAGS= -g -pipe -std=gnu99 -Wall -pedantic
CFLAGS= -g -O3 -pipe -std=gnu99 -Wall -pedantic
CXXFLAGS= -g -pipe -Wall -pedantic
CXXFLAGS= -g -pipe -std=c++0x -Wall -pedantic
CXXFLAGS= -g -O3 -pipe -Wall -pedantic
CXXFLAGS= -g -O3 -pipe -std=c++0x -Wall -pedantic

and comment out the trailing lines if I want to suppress the c++0x
standard or the optimization when using the debugger.