search for: image_rel_amd64_rel32

...#39;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 building rather than all the code being load...

...ate what the linker does) > > > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Joshua > Gerrard via llvm-dev > *Sent:* Monday, November 23, 2015 3:50 AM > *To:* llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* [llvm-dev] COFF::IMAGE_REL_AMD64_REL32 relocation overflow > when compiling for x86_64 > > > > 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...

...ng labels in a different section of the binary. To clarify, if I assemble the code: .data foo BYTE 5 .code mov eax, foo with Microsoft's ml64.exe, it emits an object file disassembling to: 0: 8b 05 00 00 00 00 mov eax, dword ptr [rip] 000000000000000b: IMAGE_REL_AMD64_REL32 foo On the other hand, if I use my current local draft of llvm-ml, I get a different result. I actually get the same result as I do for llvm-mc, using the corresponding code: .data foo: .byte 5 .text .intel_syntax mov eax, foo Either way, LLVM emits an object file with disassembly (and re...

...quicinc.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: [EXT] Re: [llvm-dev] MASM & RIP-relative addressing Clarifying a minor copy/paste error, ml64.exe actually outputs: 0: 8b 05 00 00 00 00 mov eax, dword ptr [rip] 0000000000000002: IMAGE_REL_AMD64_REL32 foo In other words, the relocation info is the same... but the instruction uses RIP-relative addressing, not absolute. On Tue, Jan 21, 2020 at 5:41 PM Eric Astor <epastor at google.com<mailto:epastor at google.com>> wrote: Apologies - I apparently remembered part of the issue i...

...d-rise-is-like-3d-touch-for-musicians-11404216/>*”. Now available for preorder at **www.roli.com* <http://www.roli.com/>*.* On 14 October 2015 at 06:48, Lang Hames <lhames at gmail.com> wrote: > Hi Joshua, Andy, > > I'm afraid I'm not familiar with COFF. Andy - is IMAGE_REL_AMD64_REL32 > unexpected if you're compiling for 64-bit mode? It sounds like it from your > description above. > > I'll look in to the "BSS sections don't have contents" error tomorrow: It > looks like it's happening in platform-agnostic RuntimeDyld code, so > hopefu...

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

...er at www.roli.com <http://www.roli.com/>. >> >> >> >> On 14 October 2015 at 06:48, Lang Hames <lhames at gmail.com <mailto:lhames at gmail.com>> wrote: >> Hi Joshua, Andy, >> >> I'm afraid I'm not familiar with COFF. Andy - is IMAGE_REL_AMD64_REL32 unexpected if you're compiling for 64-bit mode? It sounds like it from your description above. >> >> I'll look in to the "BSS sections don't have contents" error tomorrow: It looks like it's happening in platform-agnostic RuntimeDyld code, so hopefully I can r...

Hi all, Continuing work on llvm-ml (a MASM assembler)... and my latest obstacle is in enabling MASM's convention that (unless specified) all memory location references should be RIP-relative. Without it, we emit the wrong instructions for "call", "jmp", etc., and anything we build fails at the linking stage. My best attempt at this so far is a small patch to

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

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