Displaying 10 results from an estimated 10 matches for "rel32".
Did you mean:
reg32
2020 Aug 24
2
ORC JIT - Incorrect support for COFF files?
Hey Lang and Stefan,
Using dllimport on my “planschiValue” actually worked! But I have no idea why, because the relocation is still a REL32 if I use dumpbin… So how is it possible for that to work?
However… when I load an COFF object file, am I able to change the relocations to dllimport somehow? I honestly can’t imagine how this would work since the machine code is probably already adjusted to use a REL32… or something… Just wanted to...
2020 Aug 25
2
ORC JIT - Incorrect support for COFF files?
...itz <stefan.graenitz at gmail.com>; LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] ORC JIT - Incorrect support for COFF files?
Hi Bjoern,
Using dllimport on my “planschiValue” actually worked! But I have no idea why, because the relocation is still a REL32 if I use dumpbin…
From memory dllimport is like a GOT access: You'll have a REL32 either way, but instead of a REL32 directly to the variable you'll end up with a REL32 to an entry in a pointer table containing the address of the variable, and the code sequence will change to access the va...
2012 Jan 03
2
[LLVMdev] 'Reference Out Of Range' error building llvm/clang with -O4
This is compiling the Trunk revision from last Friday:
reference out of range from _llvm_regerror (1000437F0) in
../../lib/libLLVMSupport.a(regerror.c.o) to cstring=0 (0) in
../../lib/libLLVMSupport.a(regerror.c.o)
ld: rel32 out of range in _llvm_regerror from
../../lib/libLLVMSupport.a(regerror.c.o)
clang-3: error: linker command failed with exit code 1 (use -v to see
invocation)
OS X 10.6, compling LLVM with LLVM using -O4
2020 Aug 21
2
ORC JIT - Incorrect support for COFF files?
...ction only. I didn't
consider member function calls, etc. (addend is always 0) because it was
not relevant for the specific issue.
Hope it helps
Stefan
On 21/08/2020 13:22, Gaier, Bjoern via llvm-dev wrote:
>
> I figured out that this problem is caused because “planschiValue” has
> a REL32 relocation and the addresses between the code and the variable
> overflows 32bit.
>
> Is there any workaround for this kind of issue?
>
>
>
> *From:*llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of
> *Gaier, Bjoern via llvm-dev
> *Sent:* 20 August 2020...
2020 Apr 08
0
[RFC PATCH 14/26] x86/alternatives: Handle native insns in text_poke_loc*()
On Tue, Apr 07, 2020 at 10:03:11PM -0700, Ankur Arora wrote:
> struct text_poke_loc {
> s32 rel_addr; /* addr := _stext + rel_addr */
> - s32 rel32;
> - u8 opcode;
> + union {
> + struct {
> + s32 rel32;
> + u8 opcode;
> + } emulated;
> + struct {
> + u8 len;
> + } native;
> + };
> const u8 text[POKE_MAX_OPCODE_SIZE];
> };
NAK, this grows the structure from 16 to 20 bytes.
2020 Aug 20
2
ORC JIT - Incorrect support for COFF files?
Hey LLVM-Mailing-List and Lang,
I'm still learning how to use the ORC JIT but I finally reached the point to JIT and execute some code. For this purpose I created a test file (TestModule.cpp) and compiled it with Clang, generating two different files, one in the LLVM IR format and one in the Microsoft COFF format.
The JIT resolves all undefined references, including "extern int
2015 Nov 23
2
COFF::IMAGE_REL_AMD64_REL32 relocation overflow when compiling for x86_64
...cro 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...
2016 Jul 06
2
Status of stack walking in LLVM on Win64?
Can we accept the patch which makes this work? There is a patch in the
bug report for the MCJIT case. I'm confused why AOT and MCJIT case
would be different but without it the information isn't registered.
On Wed, Jul 6, 2016 at 9:07 AM, Reid Kleckner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> If you want an AOT linker and you don't want to use link.exe, you can use
2015 Nov 23
3
COFF::IMAGE_REL_AMD64_REL32 relocation overflow when compiling for x86_64
...ker 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...
2016 Nov 17
4
RFC: Insertion of nops for performance stability
Hi all,
These days I am working on a feature designed to insert nops for IA code generation that will provide performance improvements and performance stability. This feature will not affect other architectures. It will, however, set up an infrastructure for other architectures to do the same, if ever needed.
Here are some examples for cases in which nops can improve performance:
1. DSB