search for: setrelocationmodel

...ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in <...>. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie This novice developer thought that the solution would be: engineBuilder.setRelocationModel(Reloc::PIC_); However this has no diff in the resulting object file. Have I overlooked something simple? Is this feature not supported and I need to link with -Wl,-no_pie? Thanks in advance! v/r Josh TL;DR: engineBuilder.setRelocationModel(Reloc::PIC_) appears to have no effect when generating...

...hin 2GB of of what it's calling, so the offset may > be too big. > > > The goal is to be able to move the entire JIT program memory somewhere > else and still be able to run the program. > > It sounds like you need to configure the ExecutionEngine to use PIC > mode with setRelocationModel. With that, LLVM do some GOT magic to get > the right address to jump to and then use an absolute jump to that > register. You still have to arrange for the GOT to contain the right > value (looks like it's the address of the function relative to the > start of the GOT at first glan...

Hi, Is it possible to tell LLVM somewhere that we prefer the asm printer to use x64 relative CALL (0xFF) instead of absolute one ? The goal is to be able to move the entire JIT program memory somewhere else and still be able to run the program. Thanks ! -------------- next part -------------- An HTML attachment was scrubbed... URL:

...al linker doesn’t > patch the instruction, does the ELF loader always try to load .rodata > segments in the low 2GB of memory regardless of if it is from the main image > or from a shared library? > > > > Thanks for any help. Perhaps you're missing a call to TargetMachine::setRelocationModel? It sounds like you need PIC codegen. -Eli

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 plausible at a glance, but I'm not really up to speed on x86 assembly. Is PIC supposed to work with JIT on X86-32? On Sat, Mar 16, 2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.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 generating JMPQ instructions using X86::reloc_absolute_word_sext relocations which we are unable to patch to the jump table in the .rodata segment

...>>> be too big. >>> >>> > The goal is to be able to move the entire JIT program memory somewhere >>> else and still be able to run the program. >>> >>> It sounds like you need to configure the ExecutionEngine to use PIC >>> mode with setRelocationModel. With that, LLVM do some GOT magic to get >>> the right address to jump to and then use an absolute jump to that >>> register. You still have to arrange for the GOT to contain the right >>> value (looks like it's the address of the function relative to the >>&gt...

...inker doesn't > patch the instruction, does the ELF loader always try to load .rodata > segments in the low 2GB of memory regardless of if it is from the main image > or from a shared library? > > > > Thanks for any help. Perhaps you're missing a call to TargetMachine::setRelocationModel? It sounds like you need PIC codegen. -Eli _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...f("Planschi...\n"); printf("The magic value is %i 0x%p && 0x%p\n", magicValue, &magicValue, pValue); } void setMagicValue(int value) { magicValue = value; } This is the code which I will load as PIC, for the JTMB I use the following settings: JTMB->setRelocationModel(llvm::Reloc::PIC_); JTMB->setCodeModel(llvm::CodeModel::Small); The code will be loaded into a shared memory. Two process will execute the memory from there, calling "printMagicValue", "setMagicValue(120)" and "printMagicValue" again. Only the first process will JIT...

...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 plausible at a glance, but I'm not really up to speed on x86 assembly. Is PIC supposed to work with JIT on X86-32? On Sat, Mar 16, 2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com> wrote: > >...

...or 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 plausible at a glance, but I'm not really up to speed on x86 assembly. > Is PIC supposed to work with JIT on X86-32? > > On Sat, Mar 16, 2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com&...

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

...or 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 plausible at a glance, but I'm not really up to speed on x86 assembly. > Is PIC supposed to work with JIT on X86-32? > > On Sat, Mar 16, 2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com&g...

...or 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 plausible at a glance, but I'm not really up to speed on x86 assembly. > Is PIC supposed to work with JIT on X86-32? > > On Sat, Mar 16, 2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com&g...

> 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

...inker doesn't > patch the instruction, does the ELF loader always try to load .rodata > segments in the low 2GB of memory regardless of if it is from the main image > or from a shared library? > > > > Thanks for any help. Perhaps you're missing a call to TargetMachine::setRelocationModel? It sounds like you need PIC codegen. -Eli _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...or 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 plausible at a glance, but I'm not really up to speed on x86 assembly. > Is PIC supposed to work with JIT on X86-32? > > On Sat, Mar 16, 2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com&g...