search for: applyfixup

...Int().getHiBits(32).getLimitedValue()); } else if (MO.isExpr()) { const MCExpr *p_expr = MO.getExpr(); Fixups.push_back(MCFixup::Create(0, p_expr, MCFixupKind(Mips::fixup_Mips_Branch_PCRel))); } return 0; } ############################################ Later in MipsAsmBackend.cpp:ApplyFixup() I find the value is the offset of the target value from the beginning of the section and not the delta from the branch address. I also get a relocation request even though the label should be resolved. So, I must not be telling the compiler what to do when setting up the relocation. What am I d...

Big thanks, i've managed to find what's going on. The thing that dumbfolded me a couple of times was that the error was thrown in one of the MCAssembler methods, but never in applyFixup() itself. On Thu, Jan 19, 2017 at 8:46 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/19/2017 10:21 AM, Peter Bel wrote: > >> Hi, >> >> For the function call - yes, probably. But what about branching inside >> one function (standard if-then for ex...

...se if (MO.isExpr()) { > const MCExpr *p_expr = MO.getExpr(); > Fixups.push_back(MCFixup::Create(0, p_expr, > MCFixupKind(Mips::fixup_Mips_Branch_PCRel))); > } > return 0; > } > > ############################################ > > Later in MipsAsmBackend.cpp:ApplyFixup() I find the value is the offset > of the target value from the beginning of the section and not the delta > from the branch address. > I'm not sure I follow. Wouldn't that still require a relocation from the start of the section? > I also get a relocation request even though...

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 bound...

Hello, I notice that the program compiled by llvm-trunk compiler can't run correctly on hexagon-sim. The problem may caused by unimplemented backend applyFixup function. void applyFixup(MCFixup const & /*Fixup*/, char * /*Data*/, unsigned /*DataSize*/, uint64_t /*Value*/, bool /*IsPCRel*/) const override { return; } Best regards, Mingjie

Hi, For the function call - yes, probably. But what about branching inside one function (standard if-then for example)? For example: echo "int g() { int a = 1; if (a > 3) return 1; return 0; }" | clang -x c - -o /tmp/a.o -c && objdump -d /tmp/a.o Thanks, Petr On Thu, Jan 19, 2017 at 8:06 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/19/2017 9:11

...be as perverse as they want with expressions, resulting with possibly multiple relocations and an immediate for a given instruction operand. Is expression layering described in the documentation anywhere? Cheers, Jack ________________________________________ > > Later in MipsAsmBackend.cpp:ApplyFixup() I find the value is the offset > of the target value from the beginning of the section and not the delta > from the branch address. > I'm not sure I follow. Wouldn't that still require a relocation from the start of the section? > I also get a relocation request even though...

...Target &T, const StringRef TT, uint8_t _OSABI) - : ARMAsmBackend(T, TT), OSABI(_OSABI) { } + : ARMAsmBackend(T, TT), OSABI(_OSABI) { + // FIXME: Are there versions of ELF-ARM that do not support data-in-code? + HasDataInCodeSupport = true; + } void applyFixup(const MCFixup &Fixup, char *Data, unsigned DataSize, uint64_t Value) const;

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same

Hi LLVM and GCC developers, My sincere thanks will goto: * Duncan, the core developer of llvm-gcc and dragonegg http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf * David, the innovator and developer of GCC https://dmalcolm.fedorapeople.org/gcc/global-state/requirements.html and others who give me kind response for teaching me patiently and carefully about how to migrate GCC v4.8.x to

..., 0, 0 } + }; + if (Kind < FirstTargetFixupKind) + return MCAsmBackend::getFixupKindInfo(Kind); + + assert(unsigned(Kind - FirstTargetFixupKind) < getNumFixupKinds() && + "Invalid kind!"); + return Infos[Kind - FirstTargetFixupKind]; + } + + void applyFixup(const MCFixup &Fixup, char *Data, unsigned DataSize, + uint64_t Value) const { + unsigned NumBytes = getFixupKindInfo(Fixup.getKind()).TargetSize / 8; + Value = adjustFixupValue(Fixup.getKind(), Value); + if (!Value) + return; // Doesn't change encoding. + +...