search for: mcfixup

Hi, I'm trying to implement a 10-bit relocation that does not start at the beginning of a byte-boundary and I'm not entirely sure I understand the use by some targets of MCFixup.Offset and MCFixupKindInfo.TargetOffset. LLVM's documentation states that: MCFixup.Offset -"/// The byte index of start of the relocation inside the encoded instruction." MCFixupKindInfo.TargetOffset - "/// The bit offset to write the relocation into." So if the relocatio...

Hi, I would like to use a MCFixup to encode the distance in number of bytes from an instruction to the end of the .text section. Is there an existing MCFixup type I can use for this? If not, does anyone have any suggestions for how to add a new MCFixup type that will do this? Thanks, Tom

> Also what is the preferred method for MC way of setting out subsection > sizes after the fact? I am guessing I need to use an MCFixup? > How do I get an MCExpr to evaluate a method for the subsection size? > Is there an equivalent use in the places using MCFixup? > Do I need to add a new subclass to MCExpr for doing this? > > JimG, can you please comment on the MachO specific parts in the > ARMAsmPrinter.cpp? Is...

...nding why these fixups are being created. When compiled on AVR, I get the error "LLVM ERROR: expected relocatable expression”. If I compile to asm, I get these fixups… llc -march=avr -mcpu=atmega328p cause-relocation-error.ll -filetype=obj -debug 2>&1| grep unnamed_4 Fixups:[<MCFixup Offset:0 Value:(__unnamed_4&65535)-((_TMRfV4main10Brightness&65535)+16) Kind:2>]>, (__unnamed_4, Index:0, ), Fixups:[<MCFixup Offset:0 Value:(__unnamed_4&65535)-((_TMRfV4main10Brightness&65535)+16) Kind:2>]>, (__unnamed_4, Index:0, ),...

.../// @name Relocation Data > + /// @{ > + > + struct ELFRelocationEntry { > + // Make these big enough for both 32-bit and 64-bit > + uint64_t r_offset; > + int Index; > + unsigned Type; > + const MCSymbol *Symbol; > + uint64_t r_addend; > + const MCFixup *fixup; > + > + ELFRelocationEntry() > + : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {} > + > + ELFRelocationEntry(uint64_t RelocOffset, int Idx, > + unsigned RelType, const MCSymbol *Sym, > + uint64_...

...other remaining uses are in AsmPrinter, again to do cross platform things. It seems a bit strange to use a high level hammer to do ballpeen work..... But when in Rome.... :-) Also what is the preferred method for MC way of setting out subsection sizes after the fact? I am guessing I need to use an MCFixup? How do I get an MCExpr to evaluate a method for the subsection size? Is there an equivalent use in the places using MCFixup? Do I need to add a new subclass to MCExpr for doing this? JimG, can you please comment on the MachO specific parts in the ARMAsmPrinter.cpp? Is there an example of a "...

> Hmm, I wish we had this discussion way earlier.. > > How would I emit things in different subsections? I can do a high > level switch to .ARM.attributes, and if I were emitting one blob from > begin to end, using the higher level interface would be preferable, > but it contains additional subsections - which are naturally > represented by MCDataFragments - Is there an MC

.../ @{ >> + >> +  struct ELFRelocationEntry { >> +    // Make these big enough for both 32-bit and 64-bit >> +    uint64_t r_offset; >> +    int Index; >> +    unsigned Type; >> +    const MCSymbol *Symbol; >> +    uint64_t r_addend; >> +    const MCFixup *fixup; >> + >> +    ELFRelocationEntry() >> +      : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {} >> + >> +    ELFRelocationEntry(uint64_t RelocOffset, int Idx, >> +                       unsigned RelType, const MCSymbol *Sym, >> +  ...

...struct ELFRelocationEntry { >>> + // Make these big enough for both 32-bit and 64-bit >>> + uint64_t r_offset; >>> + int Index; >>> + unsigned Type; >>> + const MCSymbol *Symbol; >>> + uint64_t r_addend; >>> + const MCFixup *fixup; >>> + >>> + ELFRelocationEntry() >>> + : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {} >>> + >>> + ELFRelocationEntry(uint64_t RelocOffset, int Idx, >>> + unsigned RelType, const MCS...

...l. I make a call from the .td for the branch instruction which calls a routine in MipsMCCodeEmmitter.cpp. That routine ############################################################## unsigned MipsMCCodeEmitter:: getBranchTargetOpValue(const MCInst &MI, unsigned OpNo, SmallVectorImpl<MCFixup> &Fixups) const { const MCOperand &MO = MI.getOperand(OpNo); if (MO.isReg()) { unsigned Reg = MO.getReg(); unsigned RegNo = getMipsRegisterNumbering(Reg); return RegNo; } else if (MO.isImm()) { return static_cast<unsigned>(MO.getImm()); } else if (MO.isF...

On Thu, Oct 21, 2010 at 11:42 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Also what is the preferred method for MC way of setting out subsection >> sizes after the fact? I am guessing I need to use an MCFixup? >> How do I get an MCExpr to evaluate a method for the subsection size? >> Is there an equivalent use in the places using MCFixup? >> Do I need to add a new subclass to MCExpr for doing this? >> >> JimG, can you please comment on the MachO specific parts in the >&g...

...behavior sorts the relocations by the r_offset. > 2. Move struct ELFRelocationEntry from ELFObjectWriter to > MCELFObjectTargetWriter and add member fixup to it. The overridden > version of ReorderRelocs (MipsELFObjectWriter::ReorderRelocs) needs > access to ELFRelocationEntry::Type and MCFixup::Value to reorder the > relocations. > > Do you think these changes are acceptable? > > On Wed, Mar 21, 2012 at 3:50 PM, Jim Grosbach <grosbach at apple.com> wrote: >> Hi Akira, >> >> If I follow correctly, the relocation entries can thus be in a different ord...

...Relocs. The default behavior sorts the relocations by the r_offset. 2. Move struct ELFRelocationEntry from ELFObjectWriter to MCELFObjectTargetWriter and add member fixup to it. The overridden version of ReorderRelocs (MipsELFObjectWriter::ReorderRelocs) needs access to ELFRelocationEntry::Type and MCFixup::Value to reorder the relocations. Do you think these changes are acceptable? On Wed, Mar 21, 2012 at 3:50 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Akira, > > If I follow correctly, the relocation entries can thus be in a different order than the instructions that they&...

So what I am hearing is that I should add the following to MC/MCFixup.h: FK_GPRel_1, ///< A one-byte pc relative fixup. FK_GPRel_2, ///< A two-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 t...

> De : Joerg Sonnenberger [mailto:joerg at britannica.bec.de] > > The basic idea is to still create a relocation on the MC level, but fix it up later. > You didn't say if your ISA is fixed or variable length, the former, can simplify > this quite bit. The constant island pass generally tries to address two issues: > (1) Merging of identical constants. > (2) Splitting the

...t.s:4:13: error: invalid operand for instruction add r0, r0, #size ^ It works for llvm-mc if the #size is set to a constant (e.g. .set size, 0x10). I took a quick shot at implementing this for llvm. I had some success by allowing an MCExpr to impersonate a constant and then using a MCFixup to write the actual constant value later. I am not sure if this is the best approach for implementing this feature. What do others think? Is this a feature we can support for ARM? Can we (should we?) do it in a target-independent way? (filed bug http://llvm.org/bugs/show_bug.cgi?id=18202) -- Qual...

...sure the fixup needs to be Mips specific? That would be highly unusual for a data section. Normally, the data fixup is target-independent, then it's mapped to a target-dependent relocation by the object writer (the step 2 below). I strongly suspect we want to add a generic GP-relative fixup to MCFixup.h and just use that. There's nothing inherently MIPS-specific to having a global pointer. > > Daniel, are you aware of anything w/ this sort of fixup that would necessitate target-specific logic before we get to relocations? Not offhand, although we would need to know more details about...

...for the branch instruction > which calls a routine in MipsMCCodeEmmitter.cpp. That routine > > ############################################################## > unsigned MipsMCCodeEmitter:: > getBranchTargetOpValue(const MCInst &MI, unsigned OpNo, > SmallVectorImpl<MCFixup> &Fixups) const { > > const MCOperand &MO = MI.getOperand(OpNo); > > if (MO.isReg()) { > unsigned Reg = MO.getReg(); > > unsigned RegNo = getMipsRegisterNumbering(Reg); > return RegNo; > > } else if (MO.isImm()) { > return static_cast&l...

...er API (this > was motivated by DIEData) is by allowing clients to move bytes and fixups > into the MC layer. > > This is the sort of API that I was imagining: > > void MoveAndEmitFragment(SmallVectorImpl<char> &&Data, > SmallVectorImpl<MCFixup> &&Fixups); > > Note that this mirrors the fields > MCEncodedFragmentWithContents::Contents and > MCEncodedFragmentWithFixups::Fixups > and the arguments could be directly moved into the fields of a newly > created > MCDataFragment. > > Would that work for your...

...Kim <jasonwkim at google.com> wrote: > On Thu, Oct 21, 2010 at 11:42 AM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >>> Also what is the preferred method for MC way of setting out subsection >>> sizes after the fact? I am guessing I need to use an MCFixup? >>> How do I get an MCExpr to evaluate a method for the subsection size? >>> Is there an equivalent use in the places using MCFixup? >>> Do I need to add a new subclass to MCExpr for doing this? >>> >>> JimG, can you please comment on the MachO specific...