similar to: Clang/LLVM JIT - When to use "registerEHFrames()"

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

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

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

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

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

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

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

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

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

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

Still no progress with this problem. Only that non-member functions seems to be working... Also: Even when I set the target triple of the Module (when the file was parsed at runtime) to "COFF" nothing changes... From: Bjoern Gaier/HE/HORIBA To: llvm-dev at lists.llvm.org Cc: cfe-dev at lists.llvm.org Date: 08.02.2018 12:28 Subject: Re: Calling virtual elf functions

Just to make sure: Both Operatingsystems have the same architecture (x64 or x86)? And in both cases you JIT to the same Architecture? 2018-02-05 16:21 GMT+01:00 via llvm-dev <llvm-dev at lists.llvm.org>: > 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

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@

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

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