search for: getreloctyp

...o-byte pc relative fixup. FK_GPRel_4, ///< A four-byte pc relative fixup. FK_GPRel_8, ///< A eight-byte pc relative fixup. In MC/MCStreamer.cpp MCStreamer::EmitGpRel32Value() Figure out how to mark it with the imprint of FK_GPRel_4 In MC/ELFObjectWriter.cpp MipsELFObjectWriter::GetRelocType() Add a switch case for FK_GPRel_4 to put out the correct target specific relocation. Is that correct? Did I miss anything? Thanks, Jack

...ct what needs to happen is something like: >> >> 1) In MCELFStreamer(), implement EmitGPRel32Value() to add an appropriate fixup, and >> 2) in ELFObjectWriter.cpp, teach the Mips bits what relocation type to use for that fixup, if it doesn't know already. (MipsELFObjectWriter::GetRelocType()). >> >> Regards, >> >> -Jim >> >> On Nov 15, 2011, at 9:57 AM, Carter, Jack wrote: >> >>> Well Jim, that may just  be my problem. >>> >>> As background I am working on the outer reaches of llvm for the direct object output for...

Hi Everyone, I'm working Chromium targeting Windows on ARM64 platform. As a part of this work I ran into an issue related to llvm in Swiftshader. Currently fixup_aarch64_movw relocation type is not supported for COFF ARM64 (AArch64WinCOFFObjectWriter). As far as I see, Microsoft hasn't defined indicator for this relocation type. I haven't seen documented anywhere. For AArch32

...happen, and verify our >       // behavior. >       Ctx.reportError(Fixup.getLoc(), "unresolved movw fixup not yet " >                                       "implemented"); >       return Value; >     } > > Despite this, it seems like AArch64ELFObjectWriter::getRelocType does > return some ELF/AArch64 specific relocation types for this (but which > never end up emitted to object files). > > I tried adding an error in AArch64AsmBackend.cpp for this fixup type > and running the tests in llvm/test/MC (I didn't check other parts of > the test...

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

...specific problem, I suspect what needs to happen is something like: 1) In MCELFStreamer(), implement EmitGPRel32Value() to add an appropriate fixup, and 2) in ELFObjectWriter.cpp, teach the Mips bits what relocation type to use for that fixup, if it doesn't know already. (MipsELFObjectWriter::GetRelocType()). Regards, -Jim On Nov 15, 2011, at 9:57 AM, Carter, Jack wrote: > Well Jim, that may just be my problem. > > As background I am working on the outer reaches of llvm for the direct object output for Mips. Part of what I am to do is instruct the folks working closer to the backend...

...specific problem, I suspect what needs to happen is something like: 1) In MCELFStreamer(), implement EmitGPRel32Value() to add an appropriate fixup, and 2) in ELFObjectWriter.cpp, teach the Mips bits what relocation type to use for that fixup, if it doesn't know already. (MipsELFObjectWriter::GetRelocType()). Regards, -Jim On Nov 15, 2011, at 9:57 AM, Carter, Jack wrote: > Well Jim, that may just be my problem. > > As background I am working on the outer reaches of llvm for the direct object output for Mips. Part of what I am to do is instruct the folks working closer to the backend w...

Well Jim, that may just be my problem. As background I am working on the outer reaches of llvm for the direct object output for Mips. Part of what I am to do is instruct the folks working closer to the backend what I am getting that is incorrect. My first reaction is to assume that I am being fed things the correct way and that I am not handling it correctly. I feed the compiler a source file

...em, I suspect what needs to happen is something like: > > 1) In MCELFStreamer(), implement EmitGPRel32Value() to add an appropriate fixup, and > 2) in ELFObjectWriter.cpp, teach the Mips bits what relocation type to use for that fixup, if it doesn't know already. (MipsELFObjectWriter::GetRelocType()). > > Regards, > > -Jim > > On Nov 15, 2011, at 9:57 AM, Carter, Jack wrote: > >> Well Jim, that may just be my problem. >> >> As background I am working on the outer reaches of llvm for the direct object output for Mips. Part of what I am to do is in...

...class wanting options>::createObjectWriter(...) -> create<foo>ObjectWriter(..., added information) -> <foo>ObjectWriter::<foo>ObjectWriter(..., added information) sets added state based on constructor args, in my case the ABI, IsILP32 <foo>ObjectWriter::GetRelocType(...) use state to guide which relocations are generated I don't know if the object lifetime of MCTargetOptions allows a reference to be kept around, so the information extraction in the MCAsmBackend subclass constructor may be required. Anson On Thursday, December 17, 2015 6:30 AM, Daniel...

On Wed, Apr 22, 2020 at 10:34 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Apr 22, 2020 at 9:28 AM Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: >> > >> > >> > >> > > -----Original Message-----

I am implementing a defined, but currently unimplemented by LLVM, ABI. This ABI differs from an existing ABI in its ELF object format by implementing a subset of an existing ABI, but encoded differently and by setting the e_ident EI_CLASS field. I am trying to use MCTargetOptions::getABIName to set a boolean in the modified subclass of MCELFObjectTargetWriter to indicate which relocation encoding