I have a c source code and I have a llvm ir code generated from the source code. How can I get the llvm ir code line(s) or the block which has the line(s) corresponding to a particular c source code line automatically (i.e., not manually)?
Related
Does anyone have a solution for syntax highlighting of OpenCL code for CLion?
I am placing the OpenCL source code in a file with the extension .cl and would like to have syntax highlighting for such files.
In CLion you can add .cl files as custom file types and manually provide the list of OpenCL C keywords for syntax highlighting.
There is an alternative to loading the OpenCL C code from a .cl file at runtime: Embedding it right within C++, such as used in this OpenCL-Wrapper. While naive string literals would destroy syntax highlighting, there is a way to retain syntax highlighting with the
#define R(...) std::string(" "#__VA_ARGS__" ")
stringification macro and by using #defines for all the OpenCL C functions and keywords.
I have a C source code and also its llvm bit code. Please tell me how to slice the bitcode if I give a particular line from the source code as slicing target. I am actually trying to get the branch and jump instructions or their line numbers in bit code which will allow the program to reach that block where this source code line is present in bit code format. Please tell me if it is possible at all.
I have a Fortran77 source code with lots of printing commands of the form:
write( fileID, label ) somevariable
This F77 code is compiled via "R CMD SHLIB code.f" into a DLL which is called from R. If within the F77 code fileID is a regular text file, the command works fine. However, in case for the standard console output,
that is fileID = 0 , R creates a "fort.0" temporary file, instead of showing the output within the R GUI console window.
This problem occurs only in my Windows 64bit version. Under Linux 32bit and 64bit, the output for fileID = 0 gets correctly shown in the console.
I already tried the flush.console() command. No success.
Does maybe anybody know how to resolve that issue? Re-writing the write(0,*) commands from F77 in R is unfortunately not an option.
Thanks!
You are not supposed to use native print methods in extension modules loaded into R. Writing R Extensions has this to say:
6.5.1 Printing from FORTRAN
On many systems FORTRAN 'write' and 'print' statements can be used,
but the output may not interleave well with that of C, and will be
invisible on GUI interfaces. They are not portable and best avoided.
Three subroutines are provided to ease the output of information
from FORTRAN code.
subroutine dblepr(LABEL, NCHAR, DATA, NDATA)
subroutine realpr(LABEL, NCHAR, DATA, NDATA)
subroutine intpr (LABEL, NCHAR, DATA, NDATA)
Here LABEL is a character label of up to 255 characters, NCHAR is its
length (which can be '-1' if the whole label is to be used), and DATA
is an array of length at least NDATA of the appropriate type ('double
precision', 'real' and 'integer' respectively). These routines print
the label on one line and then print DATA as if it were an R vector on
subsequent line(s). They work with zero NDATA, and so can be used to
print a label alone.
I know the C/C++ side much better and there we surely have to use Rprintf() et al in order to have the output cooperate nicely with R's own output stream.
I am new to create shared objects for R from Fortran sources. Perhaps some of my questions do not make sense. However, I have searched a lot about my questions but still get no clear answer. So, I would like to figure out what the big picture to create these shared objects(.dll files)in R is.
According some tutorials and manuals, I need to prepare a Fortran file mymodf.f, which contains only subroutines, similarly as below:
c file mymodf.f
subroutine initmod(odeparms)
external odeparms
double precision parms(3)
common /myparms/parms
call odeparms(3, parms)
return
end
subroutine derivs (neq, t, y, ydot, yout, ip)
....
return
end
subroutine jac (neq, t, y, ml, mu, pd, nrowpd, yout, ip)
....
return
end
c end of file mymodf.f
In order to create the shared object, it requires the following code:
system("R CMD SHLIB mymodf.f")
I want to use the subroutines in LAPACK to solve some linear equations or inverse matrices. What should I do so that I can call the subroutines in LAPACK? I ask this question because one needs to install packages in R to call some extra functions or one needs to add #include <xxxx.h> as header in C to call some extra functions in xxxx.h. Just the same situation.
Also, I have downloaded lapack-3.5.0.tgz from http://www.netlib.org/lapack. Where should I put package to? Do I need to install this .tgz file?
This is not a normal case to code, compile and run a Fortran program. I have some Fortran codes which is not a complete program and I want to complie it as .dll file for R.
Thanks very much for helping!
(FYI, I am working on a Windows 7 PC)
For a guy who has no experience about generating shared object from Fortran source for R, it is time-consuming to search the answer of the questions I asked above because there are really few tutorials which mention about these. It seems those who have experience about this do not see this thread.
If you want to call subroutines in LAPACK or BLAS, you need to create a file called Makevars with no file type which contains:
PKG_LIBS=$(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
Remark: you do not need to install libraries LAPACK and BLAS manually, R has already included them. All you need to do is to tell the compiler how to link them by creating the Makevars file under same directory of your Fortran source file. For other Fortran libraries, I don't know how to link them. Hope someone can provide a guide.
Then, you need to have a Fortran source, say name it my.f90 and it contains something like below:
subroutine LIN(a,b)
implicit none
integer, parameter :: n=2, nrhs=1
integer, parameter :: lda=n, ldb=n
double precision :: a(lda,n), b(ldb,nrhs)
integer :: info
call DPOSV('U',n,nrhs,a,lda,b,ldb,info)
end subroutine LIN
The next step is to compile the Fortran code as .dll file in Windows/.so file in Mac (this is so-called creating shared object for R). In order to compile the code in Windows, you need to have Rtools and R installed. Also, the path of your R should be added into "Path" of system variables. (Steps: Right click Computer icon->Properties->Advanced system settings->Environment Variables->Find and select "Path" in System variables->click "Edit" and add the path of your R, for example, C:\Program Files\R\R-3.0.2\bin;). Now, you are ready to compile the code. You need to open your R as run as administrator, change to the directory containing the Fortran file and then execute a command in R console:
system('R CMD SHLIB my.f90')
You will see that the shared object my.dll is created under the directory.
The final step is to load the shared object into R and run it. Following my example,
dyn.load('my.dll') #load the shared object
a<-diag(c(1,2)) #prepare arguments *a* and *b* for the Fortran subroutine
b<-c(3,4)
.Fortran("LIN",a=as.double(a),b=as.double(b)) #call the Fortran subroutine
Remark: you need to unload the shared object from R so that you can delete or compile over it when R is still running:
dyn.unload('my.dll')
What is the most productive and quickest way to debug shared objects that are loaded into R, in particular on OS X Mavericks? I'm primarily interested in debugging compiled Rcpp code.
I have read the R externals on debugging compiled code (http://cran.r-project.org/doc/manuals/R-exts.html#Debugging-compiled-code) which favours using gdb, but gdb isn't officially supported on Mavericks. However, it seems that lldb is a viable alternative? I found the most useful resource for working out how to debug compiled code in R from Dirk's response to this post (Thanks Dirk!) (Debugging (line by line) of Rcpp-generated DLL under Windows).
I can successfully debug compiled Rcpp code by following the steps which I outline below explicitly step by step, which other Rcpp novices may find this useful (apologies for the length, but I figure it's better to be clear than to omit and be vague). But this development process is a bit tedious and time consuming.
Questions:
is there a faster and/or easier way to debug compiled Rcpp code, compared to what I do below?
I'm a big fan of Rstudio, and would love to incorporate debugging shared objects created from that IDE, so if anyone knows how to do this, I would be interested to know? Rstudio seems to use attributes, and it appears that step 4 below needs modification, because there doesn't seem to be a .cpp file in the temporary directory after compiling (in my example below, there is no "file5156292c0b48.cpp" file)
The steps:
1) (One off) Go to the directory ~/.R (a hidden directory with the .). Create a new file called "Makevars" and in it add the line CXXFLAGS=-g -O0 -Wall.
2) In the terminal, type R -d lldb to launch R. lldb will now start.
3) Type run at the lldb command line. This will start R.
4) Compile the Rcpp code and find the location of the compiled objects. Dirk's response to the above mentioned post shows one way to do this. Here is an example I'll use here. Run the following commands in R:
library(inline)
fun <- cxxfunction(signature(), plugin="Rcpp", verbose=TRUE, body='
int theAnswer = 1;
int theAnswer2 = 2;
int theAnswer3 = 3;
double theAnswer4 = 4.5;
return wrap(theAnswer4);
')
This creates a compiled shared object and other files which can be found by running setwd(tempdir()) and list.files() in R. There will be a .cpp file, like "file5156292c0b48.cpp" and .so file like "file5156292c0b48.so"
5) Load the shared object into R by running dyn.load("file5156292c0b48.so") at the R command line
6) Now we want to debug the C++ code in this .so object. Go back to lldb by hitting ctrl + c. Now I want to set a break point at a specific line in the file5156292c0b48.cpp file. I find the correct line number by opening another terminal and looking at the line number of interest in file5156292c0b48.cpp. Say it's line 31, which corresponds to the line int theAnswer = 1; above in my example. I then type at the lldb command line: breakpoint set -f file5156292c0b48.cpp -l 31. The debugger prints back that a break point has been set and some other stuff...
7) Go back to R by running cont in lldb (the R prompt doesn't automatically appear for me until I hit enter) and call the function. Run fun() at the R command line. Now I am debugging the shared object (hit n to go to next line, p [object name] to print variables etc)....
To debug simple Rcpp scripts like this, one thing you can do is create a .cpp application (with a main) that embeds R. This way you can debug it directly with Xcode which will give you a good debugging experience.
It gets more complicate when you start to want to debug packages.
This is tough. I tried Xcode and Eclipse with a standalone C++ application, but it was so difficult to get all the headers and libraries working. Furthermore, the RcppExport code calls your real R function through a pointer which seemed to really confuse Xcode, and I couldn't step into my function.
I ended up with (gdb or lldb):
In R:
R -d lldb
In debugger, set breakpoint:
b functionName
run
In R:
.Call(etc) # or just call your R code which invokes compiled C/C++ code
Then back in debugger once break happens, you can step, examine frames, etc.
This lldb/gdb command quick reference helped a lot.
Forget about trying to do this in a GUI at this point. Hopefully Rstudio will get this going.