similar to: [cfe-dev] Running LLVMHello Pass from Clang(-cl)

Hi Bjoern, I’m a bit worried about taking symbols from modules, because some of the > symbols might change later when the code was compiled with the JIT Symbol names shouldn't change from the moment they're added to the JIT (i.e. after being fully mangled). Consistency of symbol names is a requirement for ORC to work. You could try hooking into the orc::Platform API for this:

Hey Lang, That is really cool :D Is the creation of that table a Windows thingy or is this the way the LLVM handles it? Also… since it is COFF related – the never ending story of “finding my global constructors” first of all: Yes! I tried using the “initialize” function of LLVMJIT – however this only worked when I was loading a Module. When I added the object file (from the same source) the

Hi Bjoern, Did you see my previous reply? There's no way to do this currently. ORC assumes you know all the symbols, > since you added the modules defining them. > For testing / debugging you can dump the modules to stderr using > ExecutionSession::dump, but that's about it. > Do you want the symbols for diagnostic purposes, or some other reason? Regards, Lang. On Mon, Aug

Hey Lang and Stefan, Using dllimport on my “planschiValue” actually worked! But I have no idea why, because the relocation is still a REL32 if I use dumpbin… So how is it possible for that to work? However… when I load an COFF object file, am I able to change the relocations to dllimport somehow? I honestly can’t imagine how this would work since the machine code is probably already adjusted to

Hey Lang, I would be really happy to only have one LLJIT instance and using multiple JITDylibs. However… it seems like that I don’t know enough to use them. So I wonder… 1. When I add Module A to JITDylib A and Module B to JITDylib B – where will those look for undefined symbols? Will Module A for example: will it only search itself and the MainDylib? Or would it also search in JITDylib B?

Hi Björn I made a workaround for this specific issue a long time ago for the Projucer C++ JIT Engine. It basically forwards the call to another stub that provides enough space to encode a full 64-bit address. The patch is based on LLVM 3.9, so I guess it won't work out-of-the-box on a recent release, but it may give you enough hints to figure it out on your own:

Hi Lang, Thank you for your answer! This helped me again a lot!! Also that ResourceTracker is a really neat feature! Looking forward to it! :3 I changed the title cause… there is another issue I have (sorry about that…) I’m finally allowed to investigate the ORC JIT for integration into our system, which meant I got a few days to actually play around with it. However, another problem arise

Hey Lang, Woah! That mail contains a lot of information and things I never tried yet… Actually… the entire MaterializationUnit and MaterializationResponsibility part is… quite… overwhelming >O< With “pop up” I mean… the process which is waiting for Module “Planschi” to “pop up” can not do a thing about it. It just waits until there is an table entry for it, indicating that the object file

I recently had a problem creating LLVMHello. I used this CMake file #!/bin/sh # clangcmake.sh cmake -G "Eclipse CDT4 - Unix Makefiles" -DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_ECLIPSE_VERSION=4.5 -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang ../llvm then I ran make LLVMHello and the build failed

Hey Lang, > Do you mean that the object file is produced by another process and is being loaded into your JIT process for execution, or that you want your JIT to produce code for several different processes? These are different problems with different solutions. I'll wait until I understand your use case to answer further. In the current state we don’t have a JIT only an handcrafted object

Hi, I am trying to learn LLVM by following this article http://llvm.org/docs/WritingAnLLVMPass.html I checked 2.8 version from svn, built it and now I am trying to run Hello world example as $ opt -load ./Release/lib/LLVMHello.so -analyze but unfortunately it fails: Error opening './Release/lib/LLVMHello.so': ./Release/lib/LLVMHello.so: undefined symbol:

What does that mean for my code and the idea? I'm a really unexperienced LLVM user... -----Original Message----- From: Tim Northover <t.p.northover at gmail.com> Sent: Dienstag, 15. Januar 2019 15:19 To: Gaier, Bjoern <Bjoern.Gaier at horiba.com> Cc: Stefan Gränitz <stefan.graenitz at gmail.com>; Mehdi AMINI <joker.eph at gmail.com>; llvm-dev <llvm-dev at

Hi all, I find all my passes are all broken with LLVM 3.4. Then I tried out the LLVMHello.so specified in the LLVM doc, http://llvm.org/docs/WritingAnLLVMPass.html and it also crashes. It seems all the functions in the pass do work, but LLVM crashes in the doFinalization() step. Does anyone know this problem? Thanks! Tianyin

I could actually track down the cause of the problem: mainModue->getFunction("puts")->replaceAllUsesWith( llvm::ConstantExpr::getPointerCast( llvm::ConstantInt::get(llvm::IntegerType::get(context, 64), 0xF), mainModue->getFunction("puts")->getType() ) ); The problem is the line where I receive the type of the function "puts", it will crash the application

I've built LLVM/Clang from svn under Cygwin on Windows 7. I'd like to build on the LLVMHello pass example, however, when I try: $ cd $LLVM/lib/Transforms/Hello $ make I receive a large number of errors which start with: llvm[0]: Linking Debug+Asserts Loadable Module LLVMHello.dll /cygdrive/c/Users/Graham/home/projects/llvm_cygwin/lib/Transforms/Hello/Debug+Asserts/Hello.o: In function

Graham, good morning. To build LLVMHello on cygming, you should configure llvm with --enable-shared . Even with enable-shared, you might build lib/Transforms/Hello manually. (yeah, on cygming, LLVMHello should depend on tools/llvm-shlib) And, you'd be better to build with --enable-optimized. With enable-shared, llvm-shlib tends to fail with too many debug symbols. HTH, ...Takumi

Oh, you mean opt -disable-verify? Yes, it does eliminate the crashing... Do you know what's the problem, Eric? Thanks a lot! ~t On Tue, Aug 12, 2014 at 12:42 AM, Eric Christopher <echristo at gmail.com> wrote: > Tried opt -verify on your module? > > -eric > > On Tue, Aug 12, 2014 at 12:28 AM, Tianyin Xu <tixu at cs.ucsd.edu> wrote: > > Hi all, > >

I just follow the tutorial: http://llvm.org/docs/WritingAnLLVMPass.html Actually it's not only my module, I used the LLVMHello.so (a sample module in the source tree) and get the crash (I didn't do anything :-P). ~t On Tue, Aug 12, 2014 at 12:57 AM, Eric Christopher <echristo at gmail.com> wrote: > Weird, it definitely shouldn't be crashing. How did you create your

no... I guess verifier runs by default and it points to the doFinailization() function :-( ~t On Tue, Aug 12, 2014 at 12:53 AM, Eric Christopher <echristo at gmail.com> wrote: > No idea, I was suggesting to just run the verifier to see if it would > pinpoint what's broken about the module. > > -eric > > On Tue, Aug 12, 2014 at 12:52 AM, Tianyin Xu <tixu at

Hey Bjorn, Were you able to figure this out or is it still broken for you? Our scenario is a little bit different, but I have a theory as to what may be going wrong. What linker are you using when you compile your project with clang-cl? I am wondering whether the version of the linker and/or the libraries that you are using is too old in comparison to the one used for the clang compilation.