similar to: RuntimeDyLdCOFF and RTTI on Windows

I have a similar build tree to what you describe on Windows, but I get this: $ clang -c -emit-llvm repro_input.cpp -std=c++11 -o t.bc $ lli t.bc LLVM ERROR: Program used external function '??_7type_info@@6B@' which could not be resolved! It looks like people have already reported similar issues. Have you done anything to get past this kind of problem? On Sat, Oct 22, 2016 at 7:18 AM,

That's great news, thanks! If I can be of any help, let me know. :) I'll see if I can reduce the example for the relocation issue whilst you're at it. Regards, Joshua -- Joshua Gerrard JUCE Software Developer *ROLI’s **award-winning* <http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html>* Seaboard GRAND, celebrated

First of all, thanks very much to Lang for fixing the BSS section bug; works like a charm! I’ve been unable to reproduce the 32 bit relocation on 64 bit code (I’ll let you know if I do). However, I’m still having issues with resolving the 64 bit symbol relocations. In case it’s relevant, the specific symbol my program is tripping up on is IID_IOleObject, where TargetAddress is dereferenced

Oops, sorry for the spam. That last comment was incorrect. It’s IMAGE_REL_AMD64_REL32 not _5 > On 5 Oct 2015, at 17:26, Joshua Gerrard <joshua.gerrard at roli.com> wrote: > > Additional info: when the relocation issue does occur the relocation type is IMAGE_REL_AMD64_REL32_5 > >> On 5 Oct 2015, at 17:16, Joshua Gerrard <joshua.gerrard at roli.com> wrote: >>

Hi On Windows 10 when using a debug build of LLVM 10, I get this assertion failure: Assertion failed: (KV.second.getFlags() & ~WeakFlags) == (I->second & ~WeakFlags) && "Resolving symbol with incorrect flags", file C:\work\github\llvm-10.0.0.src\lib\ExecutionEngine\Orc\Core.cpp, line 450 The same failure occurred in LLVM 9 too: Assertion failed: I->second ==

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

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

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

Hi Lang, Yeah, I remember this case. Basically what’s happening is that there are relocations for ELF on x86 that use a value that is present in the object image as part of the calculation for the final value that goes in the same location. If you ever find yourself applying relocations for a second time (for instance, because the loaded object location is remapped for out-of-proc execution)

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

It’s pretty intermittent at the moment…sometimes I get the relocation overflow issue, sometimes I get another issue about BSS sections having no contents. The source code to reproduce either is simple: #include <iostream> int main (int argc, char* argv[]) { } I’ve managed to reproduce the BSS section issue in clang consistently, and since that comes before terms of where it happens in

Thanks for the reply. I was just asking about in general whatever header files are there in Targets/ for different architectures are not including any function except this processRelocationRef() to be used in RuntimeDyldELF.cpp or RuntimeDyldCOFF.cpp or RuntimeDyldMachO.cpp and i think these files are the ones which are actually doing the relocation and linking work. So what purpose do these

Hi, Can anyone explain in lib/ExecutionEngine/RuntimeDyld/Targets/ the header files included for different architectures like RuntimeDyldCOFFX86_64.h or RuntimeDyldCOFFI386.h etc, what is the connection of these files for relocation and linking as the linking and relocation for diff architecture is done in RuntimeDyldELF.cpp, RuntimeDyldCOFF.cpp and it doesn't use any function from these

Thanks for reply, it was really helpful. Can u just be more specific and tell about processRelocationRef() and resolveRelocation() in Targets/RuntimeDyld(objectfile format)(arch).h and also in RuntimeDyldELF.cpp and how the same function is implemented in different ways in both the files ? Thanks, Siddharth On Thu, Apr 20, 2017 at 8:16 PM, mats petersson <mats at planetcatfish.com> wrote:

Some time ago I posted here regarding a relocation overflow on Windows (among other things), but the issue disappeared and so the thread got left. I've started this new thread because a) I didn't want to necro the old one and b) it felt like its own. I've now encountered the issue again and am noting down all the information I can get about it whilst it's happening. The issues is

Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor"

Hi All, I'm going to be making some API breaking changes to the ORC APIs, and to the RuntimeDyld class (which underlies MCJIT). The changes may affect MCJIT clients but are unlikely to. Where they do the fixes are likely to be trivial. ORC clients will be affected, but the fixes should also be straightforward. I have three upcoming changes in mind: 1) RuntimeDyld (the linker underlying

Thanks. I am just trying to find a relocation and linking design for Hexagon architecture, whether to follow the MIPS style of relocation or other architecture style of relocation. Thats my question . Thats why i was asking about the functions and their differences Please guide. Thanks, Siddharth On Fri, Apr 21, 2017 at 8:37 PM, mats petersson <mats at planetcatfish.com> wrote: > If

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