search for: addfixup

Hi Jack, I'm not 100% up on how MIPS represents jump tables, so take with a grain of salt and all that. Normally how this stuff works is that the streamer will create Fixups (MCDataFragment::addFixup()) for anything that might require a relocation. That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example). Then the object streamer resolves those fixups, directly...

...Jack Cc: llvmdev at cs.uiuc.edu List; Daniel Dunbar Subject: Re: [LLVMdev] MCELFStreamer subclassing Hi Jack, I'm not 100% up on how MIPS represents jump tables, so take with a grain of salt and all that. Normally how this stuff works is that the streamer will create Fixups (MCDataFragment::addFixup()) for anything that might require a relocation. That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example). Then the object streamer resolves those fixups, directly...

Hi everyone. In ARMAsmBackend.cpp, in routine DarwinARMAsmBackend::ApplyFixup() there is a curious call to getFixupKindNumBytes() - which can return 1,2, 3, or 4 depending upon the FixupKind The code in ApplyFixup() seems to be lifted from the X86. AFAIK, the initial Fixup.Offset() is always divisible by 4, at least for ARM mode - i.e. it is always at the instruction boundary. it looks like

...text addresses to the data section. I'm sure it is just a few lines of code. Any suggestions? Jack void MCObjectStreamer::EmitGPRel32Value(const MCExpr *Value) { MCDataFragment *DF = getOrCreateDataFragment(); int Size = 4; // Assumption is that this is alway for 4 byte value DF->addFixup(MCFixup::Create(DF->getContents().size(), Value, FK_GPRel_4)); DF->getContents().resize(DF->getContents().size() + Size, 0); } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.l...

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

...st; Daniel Dunbar > Subject: Re: [LLVMdev] MCELFStreamer subclassing > > Hi Jack, > > I'm not 100% up on how MIPS represents jump tables, so take with a grain of salt and all that. > > Normally how this stuff works is that the streamer will create Fixups (MCDataFragment::addFixup()) for anything that might require a relocation. That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example). Then the object streamer resolves those fixups, directly...

...; Subject: Re: [LLVMdev] MCELFStreamer subclassing >> >> Hi Jack, >> >> I'm not 100% up on how MIPS represents jump tables, so take with a grain of salt and all that. >> >> Normally how this stuff works is that the streamer will create Fixups (MCDataFragment::addFixup()) for anything that might require a relocation. That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example).  Then the object streamer resolves those fixups, directly...

...d, it is not endian safe. You can copy the MCMachOStreamer::EmitValue implementation (which is endian safe, but assumes the target is little endian). > + } > + else > + { Please put braces on same line as else. > + Fragment->getContents().resize(Size); > + Fragment->addFixup(MCFixup::Create(0, Value, > + MCFixup::getKindForSize(Size))); > + } > + > + AddFragment(Fragment); > } > > void WinCOFFStreamer::EmitGPRel32Value(const MCExpr *Value) { > @@ -156,17 +380,33 @@ void WinCOFFStreamer::EmitGPRel32Value(...

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer