similar to: ORC JIT - Incorrect support for COFF files?

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:

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, 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

Hey everyone, is there a way to get the name of all symbols that are stored ("stored" is not the right term - is it?) in my current ExecutionSession? I know by now that you can use "lookup" to get symbols, but this requires knowing those names. Mhh... I guess that is my shortest so far question xD Thank you in advance for any help! Kind greetings Björn Als GmbH eingetragen

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

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:

Hello LLVM-Mailing-List and hello Lang (I figured somebody would add you....so I did it directly. Sorry), I'm still playing around with the ORC JIT version which is available in LLVM 10. My goal is to get the address of every defined symbol in a module and an object file before the code is emitted. With the help of Lang I do this now with the lookup function of the Execution Session. Thank

Hi Bjoern, Thanks for your patience. The good news is that there is a neater way to do this: ExecutionSession's lookup methods take a orc::SymbolState parameter which describes the state that symbols must reach before a query can return (See https://github.com/llvm/llvm-project/blob/d1a7bfca74365c6523e647fcedd84f8fa1972dd3/llvm/include/llvm/ExecutionEngine/Orc/Core.h#L1273).In your case you

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, 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?

Hello LLVM people, after finishing Chapter 1 and 2 of the KaleidoscopeJIT tutorial, I started to play around with the code and now, I have even more questions than before. I hope that the people reading this could help me with it, to improve my understanding about the LLVM and the JIT. I have also the source code and binaries (Windows) available but because I don't know how the mailing list

Hey everyone, I felt this question is different from my other question - hope this is okay. So - I was playing around with the lookup function of the ExecutionSession and there are some things I don't understand. I have a .BC file with a function "?Sampler@@YAXXZ" referencing a value "?_Plansch_test@@3HA" that is not defined in that module itself. I first planed on not

Hey Lang, Thank you for your help and your patience – also for your answers in the “ORC JIT - Can modules independently managed with one LLJIT instance? + problems with ExecutionSession.lookup” mail. Both problems have the same origin so I keep writing about it here, to avoid duplication. My big problem is still handling cross references between modules with “our” name scheme. Since our old

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

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

Hi All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the

Heyho both Mailinglists, I'm not sure if I encountered a bug or if I'm doing something wrong. I compiled a "Hello World"-function with Clang to LLVM-IR code, while passing the "-mretpoline" flag. I tried jitting and calling that function with the KaleidoscopeJIT code, but when calling "lookup" for that function the application crashed. I also tried that file

But in my module this function already exist… I first want to delete it but without also deleting the calls to it… From: Boldizsar.Palotas at esa.int <Boldizsar.Palotas at esa.int> Sent: Donnerstag, 13. Dezember 2018 10:53 To: Gaier, Bjoern <Bjoern.Gaier at horiba.com> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Setting a function in a

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

Hi Hal, Who would I send those suggestions to which I would like to see - or feedback in general? Kind greetings Björn From: Finkel, Hal J. <hfinkel at anl.gov> Sent: 22 November 2019 17:10 To: Gaier, Bjoern <Bjoern.Gaier at horiba.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Attempting EuroLLVM2020 as a beginner Hi, Björn, It is a specific goal of the LLVM Foundation