Displaying 3 results from an estimated 3 matches similar to: "[LLVMdev] 2.6 JIT using wrong address for external functions"
2009 Dec 07
0
[LLVMdev] 2.6 JIT using wrong address for external functions
I had that problem too: http://llvm.org/bugs/show_bug.cgi?id=5116. To
work around the problem, you can:
* Switch to the thread-unsafe lazy jit.
* Allocate your JIT code within 2GB of your text segment.
* Find a way to look up the external function with dlsym or maybe the
ExecutionEngine's LazyFunctionCreator instead of addGlobalMapping.
* Upgrade to the top of the svn tree.
On Mon, Dec 7,
2016 Sep 12
1
Counterintuitive use of LLVMBool in C-API?
Of course, this is normal for C-APIs. But maybe change the name to
LLVMResult to propagate the real use? I am not arguing about the results
themself. They are standard. But the name is missguiding. As long as it's
consistent i know that i have to write an extra record operator in Delphi
to reflect this.
2016-09-12 11:11 GMT+02:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>:
> On
2017 Sep 18
0
Counterintuitive use of LLVMBool in C-API?
Okay after translating the headers to Delphi, i found more inconsistencies:
> LLVMTypeRef LLVMFunctionType(LLVMTypeRef ReturnType,
> LLVMTypeRef *ParamTypes, unsigned ParamCount,
> LLVMBool IsVarArg);
>
In this case it is the other way around. 0 means False and anything else
means true :/ (so it acts more like a