search for: armmccodeemitt

Hi everyone, I am getting into the ARM specific relocation for MC/ELF, and have some questions There are some x86/arm specific relocation values already, before they are lowered down to ELF reloc types (i.e. ARMRelocations.h and X86Relocations.h) As near as I can figure it, the relocation constants in (ARM|X86)Relocations.h are used only in ARMCodeEmitter, and X86CodeEmitter.cpp respectively -

...wer16: and :upper16: asm tags for .s emission Currently, movt/movw emission works correctly in .s, but not in .o emission This lead me to believe that the correct place to put the code to handle MCSymbolRefExpr::VK_ARM_(HI||LO)16 for the .o path was to place a case in getMachineOpValue() (i.e. not ARMMCCodeEmitter::getBinaryCodeForInstr like I mistakenly wrote in my prior email.) Are you implying that the movt/movw instruction definition in the .td files need to be fixed up instead to declare a new special case for .o emission via the EncoderMethod string, for the .o emission of movt/movw to be considered...

Hi everyone, Rafael has graciously given me some pointers for helping out on the ARM/MC .s emission infrastructure, and I am volunteering to do so. It looks like as of yesterday, the MC obj emitter for ARM is also incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for example) So if anyone already has started looking into this, I'd like to pool info so as to not step on toes. Any add'l tips and pointers would be greatly appreciated. Thanks! -jasonkim On Mon, Sep 13, 2010 at 3:06 PM, Rafael Espindola <espindola at google.com> wrote: &...

...M, Jason Kim wrote: > Hi everyone, Rafael has graciously given me some pointers for helping > out on the ARM/MC .s emission infrastructure, and I am volunteering to > do so. > It looks like as of yesterday, the MC obj emitter for ARM is also > incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for > example) > > So if anyone already has started looking into this, I'd like to pool > info so as to not step on toes. > Any add'l tips and pointers would be greatly appreciated. > > Thanks! > -jasonkim > > > On Mon, Sep 13, 2010 at 3:06 PM, Ra...

...rset=ISO-8859-1 > > Hi everyone, Rafael has graciously given me some pointers for helping > out on the ARM/MC .s emission infrastructure, and I am volunteering to > do so. > It looks like as of yesterday, the MC obj emitter for ARM is also > incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for > example) > > So if anyone already has started looking into this, I'd like to pool > info so as to not step on toes. > Any add'l tips and pointers would be greatly appreciated. > > Thanks! > -jasonkim > > > On Mon, Sep 13, 2010 at 3:06 PM, Rafael...

...>> Hi everyone, Rafael has graciously given me some pointers for helping >> out on the ARM/MC .s emission infrastructure, and I am volunteering to >> do so. >> It looks like as of yesterday, the MC obj emitter for ARM is also >> incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for >> example) >> >> So if anyone already has started looking into this, I'd like to pool >> info so as to not step on toes. >> Any add'l tips and pointers would be greatly appreciated. >> >> Thanks! >> -jasonkim >> >> >...

...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. These need to be all down in the Tar...

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