similar to: Execute / Interpret LLVM IR Bitcode

Hi I am looking at open projects that LLVM want to implement and it seems to be a suggestion to write an LLVM IR level debugger. Is there any existing LLVM projects out there that already does such a thing? If not, I would like to try implementing one myself. By debugger, I think it means something like gdb, where you can insert breakpoints, run code and observe layout of registers and memory at

On Mon, Jul 31, 2017 at 8:19 AM Stefan Gränitz <stefan.graenitz at gmail.com> wrote: > Hi Lang, hi David, thanks for looking into this. > > > > Did you identify many cases where "real work" (in your example, the > nullptr dereference" was being done in an error branch? > > In my own code yes, not in LLVM ;) I'd like to run it on a large example,

Hi Stefan, David, This is very interesting stuff - it adds a dimension of error security that Error/Expected can't provide on their own. I think it would be interesting to try to build a tool around this. Did you identify many cases where "real work" (in your example, the nullptr dereference" was being done in an error branch? My suspicion is that that should be rare, but that

Yes definitely, testing a small piece of code like the GlobPattern::create() example, it would mostly indicate missing unit tests or insufficient test data. In contrast to unit tests, however, it can also verify correct handling of errors passed between function call hierarchies in more complex scenarios. For this I should point to the other example in the code, where it's applied to

Hello, this is a call for feedback: opinions, improvements, testers.. I use the support classes Expected<T> and ErrorOr<T> quite often recently and I like the concept a lot! Thanks Lang btw! However, from time to time I found issues in the execution paths of my error cases and got annoyed by their naturally low test coverage. So I started sketching a test that runs all error paths

> I tried loading the "msvcrt.lib" as a archive. That was... a bad idea! > I get a Exception while loading: > Assertion failed: ((int64_t)Result <= INT32_MAX) && "Relocation > overflow", file > \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, line 81 It's a limitation of the COFF/PE format and unrelated to exceptions. This patch

Hi Bjoern, I'm trying to make exceptions run. I have an Object file with a function, > throwing a 1 and a second function which should catch the 1. Normal JITTING > under Windows showed me, that I have an unresolved reference to the virtual > table of type_info. Some experiments later I was able to load "msvcrt.lib" > as an archive and could resolve the reference. Nice -

Hello Stefan, I'm happy someone replied to my problem! Many thanks! To be honest... I didn't understood much of your mail. I'm a beginner with the JIT - so I will explain what I've done. To manage the memory and resolve symbols, I'm using my own Resolver-Class, which overloads the allocation and the findSymbol functions. I've noticed today, that the

I'm catching up on this. Does this mean LLVM x64 JITTed code is not exception friendly or you can't catch exceptions inside LLVM JITTed code. The first one seems to indicate that the code is not ABI friendly or that not enough information is present to notify Windows of unwind tables. I'll ask the question another way: Does LLVM emit enough information so that RtlAddFunctionTable can

Dear all, I am using LLVM C++ API to generate some code. In particular, I am dealing with AVX2 SIMD API which uses __m256i. My function input types a set of vectors and return type is also a vector. /////////////////////////////////////////////////////////////////////////////////////////// arguments.push_back(VectorType::get(IntegerType::getIntNTy(TheContext, 64), 4));//int64*4 = __m256i

Hi Stefan, Thank you very much for answering my question! I followed your suggestion but the function still cannot return the correct result. I also set target-feature attributes for my function. I am using LLVM 6.0. It only prints out some random large numbers but the correct answer is supposed to be all 0. Can you please help me figure out what's going on here? Any help will be greatly

That's encouraging. Assuming that all access to the JITted code is going to be done through a function pointer, and all JIT code is ephemeral, why is the object container format important? In fact, why is it even needed? I found it somewhat odd that MCJIT generates an object file for even the JIT case. To answer my own question, could it be that advanced JIT's may need/want to use things

Hi all, I am having hard time figuring out how I should use the API for JIT in LLVM 6. In LLVM 3.9 I am used to adding all objects at once and emitAndFinalizing them all: handle = objectLayer.addObjectSet(objectFiles, memoryManager, resolver); objectLayer.emitAndFinalize(handle); In LLVM 6.0 the objects are added one by one: auto handle = objectLayer.addObject(objectFile, resolver).get();

Maybe the easiest workaround would be overriding symbol resolution for the function name and redirect it to your own version in static code (and hope it has no bad side effect on your use case). I think when running 3rd party code, the only way to definitely avoid this kind of trouble is to never deallocate any code or data sections. Doug Binks mentioned that too in his cppcast about Runtime

Hi Joshua, Thanks for your great comment. I made up a ConstantVector in IR. Then I successfully use AVX intrinsics to retrieve the returned vector data. The remaining thing is that how to pass the vectors to LLVM function using intrinsics. Do you have any suggestions? Please forgive me if the question is too naive. I pasted below two IR I used. The first one works. The second one doesn't.

ok i have managed to compile using lli (jit) as follows: but i dont get assembly file? my sum-main.c file is: #include <stdio.h> #include<stdlib.h> int sum(int a, int b) { return a + b; } int main(int argc, char** argv) { printf("sum: %d\n", sum(atoi(argv[1]), atoi(argv[2])) + sum(atoi(argv[1]), atoi(argv[2]))); return 0; } and i used the following steps to compile. clang

Hi Christian Your use case seems to have similar requirements as remote JITing in ORC. So far I haven't used that part myself and I am sure Lang can tell you much more about it. However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2): /// Sending relocatable objects to the server (rather than fully relocated /// bits) allows JIT'd code

On Mon, Jan 14, 2019 at 3:21 AM Gaier, Bjoern via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hello LLVM-World, currently I play around with a „llvm::Module” and an external function defined there “puts”. Normally this function gets resolved in the JIT-Process but I wonder about two things: 1. Can I resolve the function already in this step? I

Hello friendly LLVM-World, because I don't know if I had send my problem to the correct Mailing-List, I will send my problem to this address too. I'm not subscribed to this list, so please add my in CC if you response. Kind regards Björn From: Bjoern Gaier/HE/HORIBA To: Clang Dev <cfe-dev at lists.llvm.org>, "cfe-dev" <cfe-dev-bounces at lists.llvm.org>

Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor"