search for: armfixupkinds

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

...if the particular data relocation required (and I do recall that MIPS has some curious ones) a custom fix-up, that still wouldn't require subclassing. For example, look at how ARM handles upper and lower. Take a look at ARM/MCTargetDesc/ARMMCExpr.h ARM/ARMAsmPrinter.cpp ARM/MCTargetDesc/ARMFixupKinds.h ARM/MCTargetDesc/ARMMCCodeEmitter.cpp ARM/MCTargetDesc/ARMMachObjectWriter.cpp - Daniel > > -Jim > >> One of the issues I hit initially with llvm is that in terms of relocation and fixups there was an assumption of universal fixups/relocation types. That was really Utopian....

On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote: > Jim, > > Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. > > The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer

Jim, Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer for a specific fixup. One of the issues I hit initially with llvm is that