Windows下Rcpp生成的DLL的调试(逐行) [英] Debugging (line by line) of Rcpp-generated DLL under Windows

查看：33 发布时间：2021/12/25 16:08:19 r debugging dll gdb rcpp

本文介绍了Windows下Rcpp生成的DLL的调试(逐行)的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

最近我一直在试验 Rcpp(内联)来生成 DLL，这些 DLL 在提供的 R 输入上执行各种任务.给定一组特定的 R 输入，我希望能够逐行调试这些 DLL 中的代码.(我在 Windows 下工作.)

为了说明，让我们考虑一个任何人都应该能够运行的特定示例...

下面的代码是一个非常简单的 cxx 函数，它只是将输入向量加倍.但是请注意，还有一个附加变量 myvar 会更改值几次但不影响输出 - 已添加此变量以便我们能够查看调试过程何时正确运行.

库(内联)图书馆(Rcpp)f0 <- cxxfunction(signature(a="numeric"), plugin="Rcpp", body='Rcpp::NumericVector xa(a);int myvar = 19;int na = xa.size();米瓦尔 = 27;Rcpp::NumericVector out1(na);for(int i=0; i < na; i++) {out1[i] = 2*xa[i];myvar++;}myvar = 101;返回(Rcpp::List::create(_["out1"] = out1));')

我们运行完上面的命令后，输入命令

getLoadedDLLs()

调出 R 会话中的 DLL 列表.列出的最后一个应该是上述过程创建的 DLL - 它有一个随机的临时名称，在我的例子中是

file7e61645c

文件名"列显示 cxxfunction 已将此 DLL 放在位置 tempdir() 中，对我来说当前是

C:/Users/TimP/AppData/Local/Temp/RtmpXuxtpa/file7e61645c.dll

现在，调用DLL的明显方法是通过f0，如下

>f0(c(-7,0.7,77))$out1[1] -14.0 1.4 154.0

但我们当然也可以使用 .Call 命令直接按名称调用 DLL:

>.Call("file7e61645c",c(-7,0.7,77))$out1[1] -14.0 1.4 154.0

所以我已经达到了直接使用 R 输入调用独立 DLL 的程度(这里是向量 c(-7,0.7,77))，并让它返回正确回答 R.

不过，我真正需要的是一种用于逐行调试的工具(我假设使用 gdb)，它可以让我观察 myvar 的值被设置为19、27、28、29、30，最后是 101，随着代码的推进. 上面的例子是故意设置的，所以调用 DLL 不会告诉我们关于 myvar 的任何信息.

澄清一下，这里的获胜条件"是能够观察到 myvar 的变化(看到值 myvar=19 将是第一步！)而无需向代码主体添加任何其他内容.这显然可能需要更改代码的编译方式(是否有调试模式设置要打开?)，或者 R 的调用方式 - 但我不知道从哪里开始.如上所述，所有这些都是基于 Windows 的.

最后一点:在我的实验中，我实际上对 cxxfunction 的副本进行了一些小的修改，以便输出 DLL - 以及其中的代码 - 接收用户定义的名称并位于用户定义的目录中，而不是临时名称和位置.但这并不影响问题的本质.我提到这一点只是为了强调，如果有人给我一个推动，那么更改编译设置应该相当容易:)

为了完整起见，在上面的原始 cxx 函数调用中设置 verbose=TRUE 显示编译参数为以下形式:

C:/R/R-2.13.2/bin/i386/R CMD SHLIB file7e61645c.cpp 2>file7e61645c.cpp.err.txtg++ -I"C:/R/R-213~1.2/include" -I"C:/R/R-2.13.2/library/Rcpp/include" -O2 -Wall -c file7e61645c.cpp -o file7e61645c.○g++ -shared -s -static-libgcc -o file7e61645c.dll tmp.def file7e61645c.o C:/R/R-2.13.2/library/Rcpp/lib/i386/libRcpp.a -LC:/R/R-213~1.2/bin/i386-lR

我改编的版本有一个与上述相同的编译参数，除了字符串file7e61645c"在任何地方都被用户选择的名称(例如testdll")替换，并将相关文件复制到更永久的位置.

预先感谢您的帮助 :)

解决方案

我对某些Rcpp 用户拥有 inline 包及其 cxxfunction().是的，它确实非常有帮助，并且肯定推动了 Rcpp 的采用使快速实验变得更加容易.是的，它允许我们在源代码中使用 700 多个单元测试.是的，我一直使用它来演示示例，位于 rcpp-devel 列表中甚至住在 presentations.

但这是否意味着我们应该在每项任务中使用它?这是否意味着它没有成本"，例如临时目录等 pp 中的随机文件名?Romain 和我在我们的文档中另有说法.

最后，调试动态加载的 R 模块是困难的.(强制性)Writing R Extensions 中有一个完整的部分关于它，Doug Bates 一两次发布了一个教程，介绍如何通过 ESS 和 Emacs(虽然我总是忘记他在哪里发布它；曾经是 rcpp-devel 列表中的 IIRCa>).

编辑 2012 年 7 月:

以下是您的步骤:

<块引用>

fun <- cxxfunction(signature(), plugin="Rcpp", verbose=TRUE, body='int theAnswer = 42;返回包装(答案)；')

我明白了

<代码>[...]编译参数:/usr/lib/R/bin/R CMD SHLIB file11673f928501.cpp 2>file11673f928501.cpp.err.txtccache g++-4.6 -I/usr/share/R/include -DNDEBUG -I"/usr/local/lib/R/site- library/Rcpp/include" -fpic -g -O0 -Wall -c file11673f928501.cpp -o 文件 11673f928501.og++-4.6 -shared -o file11673f928501.so file11673f928501.o -L/usr/local/lib/R/site-library/Rcpp/lib -lRcpp -Wl,-rpath,/usr/local/lib/R/site-库/Rcpp/lib -L/usr/lib/R/lib -lR

调用例如tempdir()查看临时目录，cd到上面使用的这个临时目录和dyn.load()上面构建的文件:

<块引用>

 dyn.load("file11673f928501.so")

现在通过发送中断信号来挂起 R(在 Emacs 中，一个简单的下拉选项).
在 gdb 中，设置一个断点.上面的单个作业对我来说变成了第 32 行，所以

<块引用>

破解文件11673f928501.cpp 32续

回到 R 中，调用函数:
<块引用>
好玩()
Presto，在我们想要的断点处的调试器中:

<块引用>

R>乐趣()断点 1，file11673f928501() at file11673f928501.cpp:3232 int theAnswer = 42;(gdb)

现在只是"由您来发挥 gdb 的魔力

现在，正如我在第一次尝试时所说的，通过一个简单的包，所有这一切(在我看来)都会变得更容易，Rcpp.package.skeleton() 可以像你一样为你编写'不必处理随机目录和文件名.但每个人都有自己的...

Recently I've been experimenting with Rcpp (inline) to generate DLLs that perform various tasks on supplied R inputs. I'd like to be able to debug the code in these DLLs line by line, given a specific set of R inputs. (I'm working under Windows.)

To illustrate, let's consider a specific example that anybody should be able to run...

The code below is a really simple cxxfunction which simply doubles the input vector. Note however that there's an additional variable myvar that changes value a few times but doesn't affect the output - this has been added so that we'll be able to see when the debugging process is running correctly.

library(inline)
library(Rcpp)

f0 <- cxxfunction(signature(a="numeric"), plugin="Rcpp", body='
    Rcpp::NumericVector xa(a);
    int myvar = 19;
    int na = xa.size();
    myvar = 27;
    Rcpp::NumericVector out1(na);
    for(int i=0; i < na; i++) {
        out1[i] = 2*xa[i];
        myvar++;
    }
    myvar = 101;
    return(Rcpp::List::create( _["out1"] = out1));
')

After we run the above, typing the command

getLoadedDLLs()

brings up a list of DLLs in the R session. The last one listed should be the DLL created by the above process - it has a random temporary name, which in my case is

file7e61645c

The "Filename" column shows that cxxfunction has put this DLL in the location tempdir(), which for me is currently

C:/Users/TimP/AppData/Local/Temp/RtmpXuxtpa/file7e61645c.dll

Now, the obvious way to call the DLL is via f0, as follows

> f0(c(-7,0.7,77))

$out1
[1] -14.0   1.4 154.0

But we can of course also call the DLL directly by name using the .Call command:

> .Call("file7e61645c",c(-7,0.7,77))

$out1
[1] -14.0   1.4 154.0

So I've reached the point where I'm calling a standalone DLL directly with R input (here, the vector c(-7,0.7,77)), and having it return the answer correctly to R.

What I really need, though, is a facility for line-by-line debugging (using gdb, I presume) that will allow me to observe the value of myvar being set to 19, 27, 28, 29, 30, and finally 101 as the code progresses. The example above is deliberately set up so that calling the DLL tells us nothing about myvar.

To clarify, the "win condition" here is being able to observe myvar changing (seeing the value myvar=19 would be the first step!) without adding anything else to the body of the code. This obviously may require changes to the way in which the code is compiled (are there debugging mode settings to turn on?), or the way R is called - but I don't know where to begin. As noted above, all of this is Windows-based.

Final note: In my experiments, I actually made some minor modifications to a copy of cxxfunction so that the output DLL - and the code within it - receives a user-defined name and sits in a user-defined directory, rather than a temporary name and location. But this doesn't affect the essence of the question. I mention this just to emphasise that it should be fairly easy to alter the compilation settings if someone gives me a nudge :)

For completeness, setting verbose=TRUE in the original cxxfunction call above shows the compilation argument to be of the following form:

C:/R/R-2.13.2/bin/i386/R CMD SHLIB file7e61645c.cpp 2> file7e61645c.cpp.err.txt 
g++ -I"C:/R/R-213~1.2/include"    -I"C:/R/R-2.13.2/library/Rcpp/include"      -O2 -Wall  -c file7e61645c.cpp -o file7e61645c.o
g++ -shared -s -static-libgcc -o file7e61645c.dll tmp.def file7e61645c.o C:/R/R-2.13.2/library/Rcpp/lib/i386/libRcpp.a -LC:/R/R-213~1.2/bin/i386 -lR

My adapted version has a compilation argument identical to the above, except that the string "file7e61645c" is replaced everywhere by the user's choice of name (e.g. "testdll") and the relevant files copied over to a more permanent location.

Thanks in advance for your help guys :)

解决方案

I am a little stunned by the obsession some Rcpp users have with the inline package and its cxxfunction(). Yes, it is indeed very helpful and it has surely has driven adoption of Rcpp further as it makes quick experimentation so much easier. Yes, it allowed us to use 700+ unit tests in the sources. Yes, I use it all the time to demonstrate examples here, on the rcpp-devel list or even live in presentations.

But does that mean we should use it for each and every task? Does it mean that it does not have "costs" such as randomized filenames in a temporary directory etc pp? Romain and I argued otherwise in our documentation.

Lastly, debugging of dynamically loaded R modules is difficult as it stands. There is an entire section in the (mandatory) Writing R Extensions about it, and Doug Bates once or twice posted a tutorial about how to do this via ESS and Emacs (though I always forget where he posted it; once was IIRC on the rcpp-devel list).

Edit 2012-Jul-07:

Here is your step by step:

(Preamble: I've used gcc and g++ for many years, and even when I add -g I don't always turn -O2 into -O0. I am really not sure you need that, but as you ask for it...)
Set your environment variable CXXFLAGS to "-g -O0 -Wall". There numerous ways to do it, some are platform-dependent (eg Windows control panel) and therefore less universal and interesting. I use ~/.R/Makevars on Windows and Unix. You could use that, or you could override R's system-wide $RHOME/etc/Makeconf or you could use Makeconf.site or ... See the full docs---but as I said, ~/.R/Makevars is my preferred way as it does NOT interfere with compilation outside of R.
Now every compilation R does via R CMD SHLIB, R CMD COMPILE, R CMD INSTALL, ... will use. So it no longer matters you use inline or a local package. Continuing with inline...
For the rest, we mostly follow 'Section 4.4.1 Finding entry points in dynamically loaded code' of "Writing R Extensions":
Start another R session with R -d gdb.
Compile your code. For

fun <- cxxfunction(signature(), plugin="Rcpp", verbose=TRUE, body='
   int theAnswer = 42;
   return wrap(theAnswer);
')

I get

[...]
Compilation argument:
 /usr/lib/R/bin/R CMD SHLIB file11673f928501.cpp 2> file11673f928501.cpp.err.txt 
 ccache g++-4.6 -I/usr/share/R/include -DNDEBUG   -I"/usr/local/lib/R/site- library/Rcpp/include"   -fpic  -g -O0 -Wall -c file11673f928501.cpp -o file11673f928501.o
g++-4.6 -shared -o file11673f928501.so file11673f928501.o -L/usr/local/lib/R/site-library/Rcpp/lib -lRcpp -Wl,-rpath,/usr/local/lib/R/site-library/Rcpp/lib -L/usr/lib/R/lib -lR

Invoke eg tempdir() to see the temporary directory, cd to this temporary directory used above and dyn.load() the file built above:

 dyn.load("file11673f928501.so")

Now suspend R by sending a break signal (in Emacs, a simple choice from a drop-down).
In gdb, set a breakpoint. The single assignment above became line 32 for me, so

break file11673f928501.cpp 32
cont

Back in R, call the function:

fun()
Presto, in the debugger at the break point we wanted:

R> fun()

Breakpoint 1, file11673f928501 () at file11673f928501.cpp:32
32      int theAnswer = 42;
(gdb)

Now it is "just" up to you to work gdb to its magic

Now, as I said in my first attempt, all this would be easier (in my eyes) via a simple package which Rcpp.package.skeleton() can write for you as you don't have to deal with randomized directories and filenames. But each to their own...

这篇关于Windows下Rcpp生成的DLL的调试(逐行)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文

Windows下Rcpp生成的DLL的调试(逐行) [英] Debugging (line by line) of Rcpp-generated DLL under Windows

问题描述

相关文章

其他开发最新文章

热门教程

热门工具

登录关闭

Windows下Rcpp生成的DLL的调试(逐行) [英] Debugging (line by line) of Rcpp-generated DLL under Windows

问题描述

相关文章

其他开发最新文章

热门教程

热门工具

登录 关闭

登录关闭