search for: homburger

Hello, I append another clue I found out: The problem is definitely not caused by "__ImageBase" the problem comes with the "OFFSET". I generated another object file which crashed. The commonality: mov edx, DWORD PTR ?normalPlanschbecken@@3HA ; normalPlanschbecken lea rcx, OFFSET FLAT :??_C at _0CC@LCMJAIPO at Reading?5?$CCnormalPlanschbecken?$CC?5?$CFi@

I wouldn't be surprised if JITing COFF files on Windows doesn't work so well, since the object file format assumes most symbols are dllimport or within the local 2GB module address range. I'm not familiar with the current JIT state of the art, though. On Thu, Mar 22, 2018 at 1:45 AM via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello, > > I append another clue I

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:

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

Hello Lang, I noticed, if I load a obj-File without a main-function, the Jitter won't resolve any address. But if I have a main, everything works fine. Why is this so? Is there a way to stop this? Kind regards Björn Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko

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

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 Lang, I'm using Windows. I was parsing an IR-File and added the Module to the ExectuionEngine. If I than searched for a function, I just got 0. But when the module had a main, I got an address. I solved the problem via a call to "generateCodeForModule". The JIT didn't even called my SymbolResolver in this special case. Could you please tell me, if there is a way to

Hello LLVM-people, I have a problem and I hope that you could help me. I'm jitting some .BC files at runtime with the LLVM under Windows 7. Thanks to the function " getImageBase()" located in RuntimeDyldCOFFX86_64.h I'm able to support exceptions. But when moving the program to Windows 10, the exceptions will crash the program. I read that the __ImageBase is important for

Heyho, I can only provide you with a screenshot for the first problem I noticed: [https://media.discordapp.net/attachments/534012750045642783/575369402195640321/unknown.png] This code will crash when calling "eeBuilder.create". But I also looked at what happens if I do reuse the llvm::ExecutionEngine. After the call to "finalizeObject" I use "removeModule" for the

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

Hello Lang, so you are part of the "Jitter-Team"? I'm really interested in this whole jitting-process. I wanted to know, is there a way to load other obj-files, than the one created with clang? Could I load - for example - a obj-File from VisualStudio? Or will the namemangeling fail? Kind regards Björn From: Lang Hames <lhames at gmail.com> To: bjoern.gaier at

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 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 LLVM-Mailing-List and Lang, I'm still learning how to use the ORC JIT but I finally reached the point to JIT and execute some code. For this purpose I created a test file (TestModule.cpp) and compiled it with Clang, generating two different files, one in the LLVM IR format and one in the Microsoft COFF format. The JIT resolves all undefined references, including "extern int

Hello again, as mentioned in a different mail, I'm a beginner with the LLVM and writing a JIT-Client under Windows. In my llvm::Module I have a certain function - now I want to delete this function, but keep all the calls and references to it. I kind of want to set the function to an external function. Is this possible? Kind greetings Björn Als GmbH eingetragen im Handelsregister Bad

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