search for: pic_

...ng 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 Reloc::PIC_ in most cases. However, if we explicitly specify Reloc::Static, our program should work on all platforms except Darwin: // If we are on Darwin, disallow static relocation model in X86-64 mode, since // the Mach-O file format doesn't support it. if (RM == Reloc::Static && TT.isOSD...

...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? > This sounds like a bug, but I can't reproduce it. Testcase? > The default Relocation Model, Reloc::Default, folds into Reloc::PIC_ > in most cases. However, if we explicitly specify Reloc::Static, our > program should work on all platforms except Darwin: > > // If we are on Darwin, disallow static relocation model in X86-64 mode, > since > // the Mach-O file format doesn't support it. > if (RM ==...

...bled. 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 object file...

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 --relocation-model=static had no effect on the output. I'm game to test it, but it would he...

...onEngine, so we use it as a wrapper for our actual allocation mechanism; this allows the code/data lifetime to be managed independently of the ExecutionEngine and Module. > Are jitted binary codes position independent? We have not found a way to do this, even when creating a TargetMachine with PIC_, but perhaps we're missing some trick. > is there a way to relocate Haven't figured that out either. > If the solution requires custom implementation of JITMemoryManager: is > there a way to get exact (or sufficient) memory size for binary code > before the actual code gene...

Hi, Can you please clarify? We're looking for a way to use LLVM to JIT many modules, assuming that the full list of modules and their content are not available at a time when some of jitted pieces are already in use. Is it feasible to destruct ExecutionEngine but keep jitted code alive? Are jitted binary codes position independent? (or is there a way to relocate) If the solution requires

...achine.cpp (actually this is show in llc --help): cl::values( clEnumValN(Reloc::Default, "default", "Target default relocation model"), clEnumValN(Reloc::Static, "static", "Non-relocatable code"), clEnumValN(Reloc::PIC_, "pic", "Fully relocatable, position independent code"), clEnumValN(Reloc::DynamicNoPIC, "dynamic-no-pic", "Relocatable external references, non-relocatable code"), clEnumValEnd)); -- With best regards, Anton Korobeyniko...

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

...sounds like a bug, but I can't reproduce it. Testcase? I've attached an example with a standard switch instruction, compiled with `llc -code-model=large`. It produces: movslq (%rax,%rdi,4), %rsi addq %rax, %rsi jmpq *%rsi >> Second, is it okay to >> silently fold into Reloc::PIC_ in this case and leave the user with >> sporadic crashes? > > > Large code model and PIC should be compatible. Technically, yes. My understanding is that, instead of a cheap implicit $rip offset, you have to materialize the value in a register and do the `add`. I don't think LLV...

...ce 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: > > On Mar 7, 2...

...y understanding is correct, I can submit a patch that will replace bool UsePlt = !Local && Subtarget.isTargetELF() && !isPPC64; with bool UsePlt = !Local && Subtarget.isTargetELF() && !isPPC64 && DAG.getTarget().getRelocationModel() == Reloc::PIC_; Vit -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171004/a23f3dbd/attachment.sig>

...at. See https://github.com/llvm-mirror/llvm/blob/f79c57a412cf8ba35884c1d4e011e07baad334d9/lib/CodeGen/SelectionDAG/TargetLowering.cpp#L281 . I think you can just force it to use EK_BlockAddress for the large code model. > >> Second, is it okay to > >> silently fold into Reloc::PIC_ in this case and leave the user with > >> sporadic crashes? > > > > > > Large code model and PIC should be compatible. > > Technically, yes. My understanding is that, instead of a cheap > implicit $rip offset, you have to materialize the value in a register >...

Anton, >> Can I ask what platform ABI's are documented other than Itanium ? > I'd bet all platform ABI are more or less documented. Right. Maybe we should collect references and do some LLVM PIC documentation and put it on LLVM website ? >> I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF >> and MachO backends. > ABI is normally induced

...*To:* llvmdev at cs.uiuc.edu > *Subject:* [LLVMdev] MIPS n64 ABI and non-PIC > > > > 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 --relocation-model=static had no effect on > the outpu...

...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 the code, every o...

...ce 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: > > On Mar 7, 2...

...ace >> >> bool UsePlt = !Local && Subtarget.isTargetELF() && !isPPC64; >> >> with >> >> bool UsePlt = !Local && Subtarget.isTargetELF() && !isPPC64 && >> DAG.getTarget().getRelocationModel() == Reloc::PIC_; >> >> Vit >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <htt...

...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: &...

...ionNumber() - << '_' << JTI << '_' << MO2.getImm() - << "_set_" << MBB->getNumber(); + O << prefix.str() << "_set_" << MBB->getNumber(); else if (TM.getRelocationModel() == Reloc::PIC_) { printBasicBlockLabel(MBB, false, false, false); // If the arch uses custom Jump Table directives, don't calc relative to JT if (!TAI->getJumpTableDirective()) - O << '-' << TAI->getPrivateGlobalPrefix() << "JTI" -...

...ipleName)); assert(MAI && "Unable to create target asm info!"); std::string MCPU("generic"); std::string FeaturesStr(""); MCObjectFileInfo MOFI; MCContext Ctx(MAI.get(), MRI.get(), &MOFI); MOFI.InitMCObjectFileInfo(TheTriple, llvm::Reloc::Model::PIC_, llvm::CodeModel::Model::Default, Ctx); std::unique_ptr<MCInstrInfo> MCII(TheTarget->createMCInstrInfo()); std::unique_ptr<MCSubtargetInfo> STI(TheTarget->createMCSubtargetInfo(TripleName, MCPU, FeaturesStr)); OK, that seems, OK. Now I want to setup an output buffer:...