[R] Debugging dynloaded C-code with gdb

Thomas Lumley thomas at biostat.washington.edu
Mon Oct 2 20:07:03 CEST 2000

On Mon, 2 Oct 2000, Peter Holzer wrote:

> Dear R users
> I have started to use gdb for debugging dynloaded C code as described in
> `Writing R Extensions'. Unfortunately I have run into several problems that
> I haven't been able to solve:
> - using `n': how comes that the same line of code appears up to three times
>   (and inbetween the next line and maybe even the second next one?)
> - using `print' resp. `display': How comes the variable values are
>   different from those shown by fprintf? How comes the variable values
>   change when actually no value is assigned to them (and I use `n', not
>   `s')?

I think both problems are likely due to compiler optimisation.  The GNU
tools are unusual in letting you debug optimised code: the Sun compilers,
for example, won't generate debugging information if you optimise, for
precisely this reason.

Optimisation typically results in the machine instructions for different
lines of C code being interleaved.  Even worse, loops may be unrolled,
statements moved in or out of loops, and other complicated things done to
your code.

While debugging optimised code can still be useful, it is often easier to
recompile the code without optimisation (as long as the bug isn't caused
by optimisation) and debug that way.

I'm not sure of the best way to recompile without optimisation. You could
edit R_HOME/etc/Makeconf, or you could cut-and-paste the compiler
invocations that R COMPILE produces and then edit them by hand.


Thomas Lumley
Assistant Professor, Biostatistics
University of Washington, Seattle

r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch

More information about the R-help mailing list