similar to: Calling virtual elf functions under windows -> Adding ASM code

Hi Björn, It's correct - I tried casting the virtual function to a regular function. > But I also tried using the virtual function in the normal way. > Yes. If I understand your setup correctly you have a base class, Interface, which is currently compiled into your application, and you are creating a derived class in JIT'd code, and returning an Interface pointer to an instance of

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

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

Historically? I implemented support for exceptions back in LLVM 3.3, before LLVM had an implementation of a Windows unwinder. Currently? As recent as LLVM 4.0, I don't think the JIT was fully capable of handling COFF files, and LLVM wouldn't emit the correct sections (with the COFF-formatted unwind tables) when used in ELF mode. The prolog is known to be standard since Julia disables FPO

Hi Bjoern, CCing cfg-dev (since that's where the conversation started) and llvm-dev (since it's relevant there). Do you know if there is a way to obtain the fully resolved obj-code? I > wanted to load the functions into a shared memory, but how? The only thing > I receive is a function pointer, but I don't know how large the function > 'behind' is. Even a call to

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

Hello everyone, I was following the discussion, but I have to admit, that my skills aren't high enough to follow you guys. For my current exception problem, I don't have to stick around with the PECOFF format, so I used clang to don't compile to a PECOFF, but to a ELF file. Interesting, now I'm missing the functions: __cxa_allocate_exception __cxa_throw _ZTI I loaded the DLL

Hello everyone, I'm sorry for "flooding" your inbox, but I wanted to extend my message which is shown below. The problem is still not solved and I'm more confused then before. I compiled the code - the one seen in the pictures to elf bc and to msvc (pecoff) bc. Then I used llc to generate assembler output. In my opinion the involved functions are acting exactly the same.

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>

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

> So... there is no way to make throw and catch working in a jitted code > under Windows? > I have used throw and catch in jitted code, so "no way" is too strong. But there's a large range of possible states between "no way" and "always enabled OOTB". Currently, this is pretty close to the "mostly unimplemented" side of the spectrum in LLVM.

Hello LLVM-People, I'm still a beginner with the LLVM, but I really like the concept and the possibilities with the JIT. Currently I compile simple functions with clang-cl into bitcode files. After this I use another program to JIT this bitcode files and execute functions of it - like lli. Thanks to a lot of mails and so on, I understood that a bitcode file is in fact still IR-Code, but

> 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 Björn To first answer your questionin the subject: For x86 registerEHFrames() is only a stub. For x86_64 registerEHFrames() is implemented properly in RuntimeDyldCOFFX86_64, calling MemMgr.registerEHFrames() for each EH frame section. It should be called and work out of the box without your involvement, but unfortunately it won't solve your issue. All the essential information is there in

Hi Björn, I'm not sure I understand what you are actually trying to achieve. Do you want to be able to debug from your main code, and step into the JITed code? Do you want to be able to set breakpoints, list callstacks, etc in the JITed code? Do you want to, from a crash, identify where in your JITed code it went wrong? The first two are definitely one or more order(s) of magnitude harder

The debug information is actually still in a different format in the .bc file, it is LLVM metadata. I think the best reference for it is here: https://llvm.org/docs/SourceLevelDebugging.html#ccxx-frontend You can dump it just by disassembling the .bc file to textual IR using llvm-dis and examining the !DI* metadata nodes. You will have to run the file through llc to generate an object file to

Hello everyone, I have some questions about the possibilities with the LLVM but I'm not sure where to gather the information. 1.) Can I teach the LLVM new platform depended intrinsics? Like I provide assembly code and want to create a custom intrinsic for it. 2.) Does the IR language have some kind of template support? I'm not sure if this even possible - but I thought about having a

Hello everyone reading this, I'm totally confused and need an explanation. I'm also not sure if it's a clang or a LLVM subject. I'm working with Visual Studio 2015, LLVM 5.0.1 and Windows 7 64bit. I have a simple project. With 2 Header files and 1 cpp file. "Interface.h" This file defines a simple class with two pure virtual member functions.