I want to ask what is the simplest way to build a parser to recognise my customised pragmas in C/C++ code. Yes, a simple bash script can do but I am wondering if there is any formal way to do through Clang or LLVM? I tried to check Clang AST but I cannot find any pragmas.
For instance:
int foo1(){
#pragma hi k=1
...
}
int foo2(){
#pragma hello k=7
...
}
I want the pass returns the following:
function foo1 has hi and k=1
function foo2 has hello and k=7
Thanks.
Pragma handling needs to be done in the following parts:
Add a handler in ParsePragma.cpp file (there are examples how to do that). In this step you can parse the pragma token by token and store corresponding information in the AST (possibly the best way to transfer data from this stage to the later stages).
If you need to handle this information in the passes working on LLVM IR, then you need to attach the information previously stored into AST into an IR related classes, in your case it seems the llvm::Function is the place where to keep that. During this process it is needed to update 'lib/AsmParser/LLParser.cpp', 'lib/AsmParser/LLLexer.cpp' and 'lib/IR/AsmWriter.cpp' files. This will allow to read and write the information stored in IR.
Finally if you need to write extra information kept in IR into the assembler file then you will need to update 'lib/CodeGen/AsmPrinter/AsmPrinter.cpp' file correspondingly.
Related
I want to get loopinfo in each function by iterating through functions in Module Pass. My code is as follows:
for (auto &F:M) {
if(!F.isDeclaration()){
LoopInfo &LI = getAnalysis<LoopInfoWrapperPass>(F).getLoopInfo();
}
}
However, there is an error, I think my variable Settings should conform to the first function definition, how should I resolve.
clang-12: /llvmtest/llvm/lib/IR/LegacyPassManager.cpp:1645: virtual
std::tuple<llvm::Pass*, bool>
{anonymous}::MPPassManager::getOnTheFlyPass(llvm::Pass*,
llvm::AnalysisID, llvm::Function&): Assertion `FPP && “Unable to find
on the fly pass”’ failed. PLEASE submit a bug report to
https://bugs.llvm.org/ and include the crash backtrace, preprocessed
source, and associated run script.
You can not do this with the legacy pass manager. In the legacy pass manager, every pass could only get info from same-scoped passes -- module from module, function from function, loop from loop, plus one exception allowing function passes to get data from module passes.
With the new pass manager, you'd create a LoopAnalysisManager and add the analysis pass you want and run it. See https://llvm.org/docs/NewPassManager.html#using-analyses .
Note that most of LLVM is presently written to support both pass managers at once. If you do this, you'll need to write your pass differently from most of LLVM's passes, you can't use the types with names like "WrapperPass" that exist to support both legacy and new pass managers.
I'm would like to be able to detect which part of a program has been modified by a previous LLVM pass.
How can I tag instruction / basic blocks and function such as I can retrieve that a pass P1 has previously modified this part of the code ?
I would like to achieve something like:
// First pass
...
tag<bool>(instruction, "modified");
// Second pass
if(has_tag<bool>(instruction, "modified"))
do_something...
Is there a feature in LLVM allowing to make such tag system ?
You may wish to look at the LLVM diff engine in its the toolset:
https://github.com/llvm/llvm-project/blob/main/llvm/tools/llvm-diff/llvm-diff.cpp
If I had a lua script, say
print'hi'
How would I get the lua bytecode equivalent to it using c++? I'm not sure if I'm explaining this right though. Thanks for all your help!
You need to load a script and then dump its bytecode.
The relevant C API functions are luaL_loadfile or luaL_loadstring for loading (they use the primitive lua_load) and lua_dump for dumping.
Loading is easy to do with these helper functions.
Dumping is a bt more work because of the need to provide a writer function. It may be easier to call string.dump after loading:
// load script, leave function on the stack
lua_getglobal(L,"string");
lua_getfield(L,"dump");
lua_pushvalue(L,-3);
lua_call(L,1,1);
// string containing bytecode left on the stack
I'm new to LLVM. I am using the clang c++ API to compile multiple stub files (in c) to IR, and then stick them together using IR builder (after linking them) to eventually run via JIT.
All this works great, unless I add a functionInlining pass to my optimizations, at which point one of these function calls made in IR builder will trigger the following exception when the pass manager is run:
Assertion failed: (New->getType() == getType() && "replaceAllUses of value with new value of different type!"), function replaceAllUsesWith, file /Users/mike/Development/llvm/llvm/lib/IR/Value.cpp, line 356.
This is how I make the call instruction (pretty straight forward):
Function *kernelFunc = mModule->getFunction( (kernel->Name() + StringRef("_") + StringRef(funcName)).str());
if (kernelFunc){
CallInst* newInst = builder.CreateCall(kernelFunc, args);
}
Later the module is optimized:
legacy::PassManager passMan;
PassManagerBuilder Builder;
Builder.OptLevel = 3;
//Builder.Inliner = llvm::createFunctionInliningPass(); //commenting this back in trigger the exception
Builder.populateModulePassManager(passMan);
passMan.run( *mModule ); //exception occurs before this call returns
Any ideas what to look for?
Try running llvm::verifyModule on your module to see if it's correct. You might have an error and have been getting lucky beforehand but it tripped something up in the inliner.
In general assertions check a subset of things that can be wrong with your module but verify checks a lot more.
It could be a bug in LLVM but more than likely it's a bad module, it's easy to happen.
So I finally setup my dev environment so I could inspect the assertion call in the debugger. I turns out the basic block being replaced had a different context set than the one it was being replaced with. going back and making sure IRBuilder was using the same context as the IR parsers solved the problem.
I need to replace all WinAPI calls of the
CreateFile,
ReadFile,
SetFilePointer,
CloseHandle
with my own implementation (which use low-level file reading via Bluetooth).
The code, where functions will be replaced, is Video File Player and it already works with the regular hdd files.
It is also needed, that Video Player still can play files from HDD, if the file in the VideoPlayer input is a regular hdd file.
What is the best practice for such task?
I suggest that you follow these steps:
Write a set of wrapper functions, e.g MyCreateFile, MyReadFile, etc, that initially just call the corresponding API and pass the same arguments along, unmodified.
Use your text editor to search for all calls to the original APIs, and replace these with calls to your new wrapper functions.
Test that the application still functions correctly.
Modify the wrapper functions to suit your own purposes.
Note that CreateFile is a macro which expands to either CreateFileW or CreateFileA, depending on whether UNICODE is defined. Consider using LPCTSTR and the TCHAR functions so that your application can be built as either ANSI or Unicode.
Please don't use #define, as suggested in other responses here, as this will just lead to maintenance problems, and as Maximilian correctly points out, it's not a best-practice.
You could just write your new functions in a custom namespace. e.g.
namespace Bluetooth
{
void CreateFile(/*params*/);
void etc...
}
Then in your code, the only thing you would have to change is:
if (::CreateFile(...))
{
}
to
if (Bluetooth::CreateFile(...))
{
}
Easy! :)
If you're trying to intercept calls to these APIs from another application, consider Detours.
If you can edit the code, you should just re-write it to use a custom API that does what you want. Failing that, use Maximilian's technique, but be warned that it is a maintenance horror.
If you cannot edit the code, you can patch the import tables to redirect calls to your own code. A description of this technique can be found in this article - search for the section titled "Spying by altering of the Import Address Table".
This is dangerous, but if you're careful you can make it work. Also check out Microsoft Detours, which does the same sort of thing but doesn't require you to mess around with the actual patching.
If you really want to hijack the API, look at syringe.dll (L-GPL).
I don't think this is best practice but it should work if you put it in an include file that's included everywhere the function you want to change is called:
#define CreateFile MyCreateFile
HRESULT MyCreateFile(whatever the params are);
Implementation of MyCreateFile looks something like this:
#undef CreateFile
HRESULT MyCreateFile(NobodyCanRememberParamListsLikeThat params)
{
if (InputIsNormalFile())
CreateFile(params);
else
// do your thing
}
You basically make every CreateFile call a MyCreateFile call where you can decide if you want need to use your own implementation or the orginal one.
Disclaimer: I think doing this is ugly and I wouldn't do it. I'd rather search and replace all occurences or something.