search for: runtimedyldcoffx86_64

Thanks all - looks like RuntimeDyldCOFFX86_64 is indeed the missing link. I'm temporarily using my own code to relocate the pdata section during linking (for unrelated reasons) but I'll definitely explore the dynamic loader in more detail. I'd much prefer to use well-tested code over my sloppy 20 minute hack job :-) --------------...

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 exceptions - so what is different from Windows 7 to Windows 10? Also other __ImageBase related code - like some switch statements...

...TTED code and should also catched there. 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 Research didn't helped me! My code was compiled with /MD, but it didn't changed. So I'm still stupid D: The JITTED code must be loaded to shared memory later - there aren't libraries, so even if this would work, it wouldn't help me. I tried compiling my code with...

.... Does anyone know where it could come from ? I have disabled all optimisations (among them is the omit-frame-pointer). I have seen this bug here : https://bugs.llvm.org/show_bug.cgi?id=24233 which is quite similar but it is quite old now, and since the proposed patch has been posted, the code in RuntimeDyldCOFFX86_64.h has changed and it is difficult for me to know if it has really been fixed since or not. Could it be related to the way IR CreateAlloca are used to build local variables ? Could it be related to missing informations inside the PDB ? (I don't know if there is stack related information inside...

...tarted 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 that I am getting a relocation overflow assertion inside RuntimeDyldCOFFX86_64.h inside the COFF::IMAGE_REL_AMD64_REL32 case. However, the other thread left me with the impression that I shouldn't be getting such relocation when I'm compiling for 64 bit. The only reason I can think of for this that I'm not supposed to get 32 bit relocations in the code I'm bui...

> 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 explains it and shows a workaround: https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f > Is there no hope left? Well at least I am not aware of a solution. Am 2...

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 header file except the processRelocationRef(). The...

...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 " > 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 exceptions > - so what is different from Windows 7 to Windows 10? > > Also other __ImageBase related code - like so...

...ts.llvm.org> wrote: > 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 explains it and shows a workaround: > https://github.com/weliveindetail/pj-llvm/commit/ > 97cd336d458ae9c73232d1b539ceefcdb2f5eb0f > > Is there no hope left? > > Well...

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 the comments, just check the base classes. This thread from last year helps...

...gt;> >> 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 explains it and shows a workaround: >> >> https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f >> >> Is the...

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>

...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 explains it and shows a workaround: >> >> >> >> >> >> https:...

...;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 that I am getting a relocation overflow assertion inside > RuntimeDyldCOFFX86_64.h inside the COFF::IMAGE_REL_AMD64_REL32 case. > > However, the other thread left me with the impression that I shouldn't be > getting such relocation when I'm compiling for 64 bit. The only reason I > can think of for this that I'm not supposed to get 32 bit relocations in...

...t; >> I have disabled all optimisations (among them is the omit-frame-pointer). >> >> I have seen this bug here : https://bugs.llvm.org/show_bug.cgi?id=24233 which >> is quite similar but it is quite old now, and since the proposed patch has >> been posted, the code in RuntimeDyldCOFFX86_64.h has changed and it is >> difficult for me to know if it has really been fixed since or not. >> >> Could it be related to the way IR CreateAlloca are used to build local >> variables ? Could it be related to missing informations inside the PDB ? (I >> don't know i...

...e > LLD. At this point it is a fully functional PE COFF linker. It lacks PDB > support, but it sounds like you don't need that yet. > > On Mon, Jul 4, 2016 at 3:45 PM, Michael Lewis via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Thanks all - looks like RuntimeDyldCOFFX86_64 is indeed the missing link. >> I'm temporarily using my own code to relocate the pdata section during >> linking (for unrelated reasons) but I'll definitely explore the dynamic >> loader in more detail. I'd much prefer to use well-tested code over my >> sloppy 20...

...> Mats > > On 20 April 2017 at 11:13, Siddharth Shankar Swain via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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 header file >> exc...

For JITs it would appear that there is a patch needed for some kind of relocations. https://llvm.org/bugs/show_bug.cgi?id=24233 Is the patch really needed? What does it do? I'm not an expert here so asking. On Sun, Jul 3, 2016 at 2:48 AM, David Majnemer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Sat, Jul 2, 2016 at 5:22 PM, Michael Lewis via llvm-dev >

You actually can mix 32 and 64 bit code in the same Windows process, but only with great effort. Fixing PR24233 is probably easier. :) We know how to generate the info, but we still have to get it registered... On Thu, Oct 29, 2015 at 2:19 PM, Lang Hames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Dibyendu, > > I'm not familiar with Windows at all, but I assume you

...g> wrote: >>>>>>> >>>>>>>> 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...