similar to: [LLVMdev] Generating PIC object files from the LLVM API

Hi, We were just debugging a sporadic crash the other day, when we noticed that RIP-relative addressing was being used in a JumpTable, even when code and data were well over 4G apart. This is confusing, because we picked CodeModel::Large, and expected this to be taken care of. Isn't that what gcc would do given a Large CodeModel? The default Relocation Model, Reloc::Default, folds into

Hello everyone, I have an issue with some code that I jit/load as position independent code. I have a feeling that it is not possible to solve the issue but I wanted to give it a try. #include <stdio.h> int magicValue = 123; int magicValue2 = 321; volatile int *pValue = &magicValue; void printMagicValue() { printf("Planschi...\n"); printf("The magic

On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > We were just debugging a sporadic crash the other day, when we noticed > that RIP-relative addressing was being used in a JumpTable, even when > code and data were well over 4G apart. This is confusing, because we > picked CodeModel::Large, and expected this to

Thanks for the reply, nice to have some validation. I thought of another approach which might be preferable: generate relocatable code, use a JITEventListener to grab each function and copy it to my own memory, let all the LLVM stuff die normally then use my copy of the code. However when I call setRelocationModel(Reloc::PIC_) on the engine builder I get code that seg faults. The assembly looks

Eli Friedman wrote: > On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> We were just debugging a sporadic crash the other day, when we noticed >> that RIP-relative addressing was being used in a JumpTable, even when >> code and data were well over 4G apart. This is confusing, because we >> picked

I'm not sure I see why the delegating memory manager feels wrong to both of you. That's exactly the kind of usage model I would envision for clients that needed to handle multiple ExecutionEngines that had reason to share a memory manager. I'm saying this as an invitation to discussion, not to be argumentative. We certainly could change things if it would make the design better.

On Fri, Jul 29, 2016 at 9:57 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Eli Friedman wrote: > > On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> We were just debugging a sporadic crash the other day, when we noticed > >> that RIP-relative addressing was being used in a

Hi Andy, One of the issues that I found not intuitive, is that when an ExecutionEngine is deallocated, the memory manager's destructor is also called. This resulted in having to write two objects in my case, one as a per JIT request memory manager and one global JIT memory manager. The per request JIT memory manager gets memory from the global manager, but both ended up implementing

Hi Dirkjan, Are you using JIT or MCJIT? Cheers. ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Dirkjan Bussink [d.bussink at gmail.com] Sent: Saturday, March 23, 2013 8:18 AM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation Hi Andy, One

It seems wrong to delegate a dozen or more methods when I only want to change the behavior in a couple small ways. It would have been easier to derive a class, but the base class is inaccessible (in an anonymous namespace). And I was afraid to roll my own memory manager because I didn't understand what all those methods do. So MCJIT is future - will JITMemoryManager remain relevant? If so I

Has anyone experimented with generating non-PIC for MIPS64 and the n64 ABI? Currently MipsISelLowering.cpp uses conditions like: if ((getTargetMachine().getRelocationModel() == Reloc::PIC_) || IsN64) { } around any PIC code generation. Is generating non-PIC just untested, or is it known not to work? I can't find any discussion of it anywhere. I ran into this when trying to see why

Aaron, > Maybe we should collect references and do some LLVM PIC documentation and > put it on LLVM website ? What you mean as "LLVM PIC documentation"? What should be included there? > Okay. We need documentation, what is the difference between DynamicNoPIC and > full PIC ? >From TargetMachine.cpp (actually this is show in llc --help): cl::values(

> On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > > > Or maybe would it be possible to have a custom allocator for memory space for the native code that we could provide? With this last option we would be responsible for the clean up ourselves and just provide memory space to LLVM where it can store the results. > > > > Yes, you should be

Hi, Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? I tried to play with TargetOptions without any success… Here is the kind of code we use to allocate the JIT: EngineBuilder builder(fResult->fModule);

Hello, I am currently facing an issue at linking stage when compiling basic C code for an embedded PPC32 platform and linking with LLD. For external symbol linkage LLVM appears to use PLT which results in generating a R_PPC_PLTREL24 relocation, that is not support by LDD. Therefore even such a basic example cannot be built: /* s.c */ int f() { return 0; } /* t.c */ int f(); int _start() {

On Thu, Jun 17, 2010 at 12:38 PM, Smith, Tim <tim at bioware.com> wrote: > (llvm 2.6) > > > > We have an application where we are using LLVM to generate ELF object files > for X86_64.   At runtime we load these objects files into memory using our > own ELF loader. > > > > Everything is working except for the jump tables. > > > > The ELF emitter is

ELF module of type ET_REL (Relocable module), generated by LLVM, always has some R_X86_64_32 in debug information sections. This happens with Reloc models Default,Static,PIC_ and with CodeModel set to Large. What is the way to prevent R_X86_64_32 ELF from ever appearing in ELF? Yuri

On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: > I derived a class from JITMemoryManager which delegates everything to > an instance made with CreateDefaultMemManager(). ExecutionEngine > destroys the wrapper, but I keep the inner instance which did the > actual work. Works, but seems a bit ugly. Did you find any other > solutions? I ended up

Actually, GCC will generate non-PIC for n64. Maybe that is a recent addition, but we are using its results. Even if PIC may be faster and smaller code, it seems that non-PIC is still useful for bare-metal. That's the driver of my interest. I guess we can just test what happens when that part of the conditional is removed. As a side note, if it isn't supported then we should probably

I had this problem a while back and received this response from Jeffrey. FWIW this is fixed in 2.7 by defaulting to CodeModel::Large and using indirect (far) calls. -----Original Message----- From: Jeffrey Yasskin [mailto:jyasskin at google.com] Sent: Monday, December 07, 2009 11:32 AM To: Howell, Nathan Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] 2.6 JIT using wrong address for