search for: emitinsttodata

Hi, I have kept working on this and found the following (as llvm 3.5): 1) In the function MCObjectStreamer::EmitInstruction there is a check for the instruction being relaxable or not: if (!Assembler.getBackend().mayNeedRelaxation(Inst)) { EmitInstToData(Inst, STI); return; } At this stage, the instruction as been already selected to be ARM::ADR. The call to mayNeed 2015-07-07 18:06 GMT+03:00 Tim Northover <t.p.northover at gmail.com>: > On 7 July 2015 at 06:06, Eric Bentura <ebentura at gmail.com> wrote: > > I have cr...

...a (anonymous namespace)::X86MCCodeEmitter::encodeInstruction(llvm::MCInst const&, llvm::raw_ostream&, llvm::SmallVectorImpl<llvm::MCFixup>&, llvm::MCSubtargetInfo const&) const lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:1512:67 #10 0x00000000015884b3 llvm::MCELFStreamer::EmitInstToData(llvm::MCInst const&, llvm::MCSubtargetInfo const&) lib/MC/MCELFStreamer.cpp:478:26 #11 0x00000000015aadc0 llvm::MCObjectStreamer::EmitInstruction(llvm::MCInst const&, llvm::MCSubtargetInfo const&) lib/MC/MCObjectStreamer.cpp:245:5 #12 0x00000000007a036b llvm::X86AsmPrinter::EmitAndC...

...I'd say that MCFixup.Offset = 1 and MCFixupKindInfo.TargetOffset = 3 and this is somehow confirmed by the code in MCAsmStreamer::AddEncodingComment. All the relocation bits are correctly identified if I emit the encoding of an instruction. The other use of MCFixup.Offset is in MCELFStreamer::EmitInstToData and it looks like it uses MCFixup.Offset to calculate r_offset (Elf32) which is not what I was expecting because I get a slightly skewed offset (off by MCFixup.Offset). I can obviously create the relocation with MCFixup.Offset to be 0 (which most of the targets do) but the code in MCAsmStreamer::...

...rote: > >> Is getBinaryCodeForInst the best place to place the case for >> supporting movt/movw fixup emission? >> The call stack seems to be: >> >> #0 ARMMCCodeEmitter::getBinaryCodeForInstr >> #1 ARMMCCodeEmitter::EncodeInstruction >> #2 MCELFStreamer::EmitInstToData >> #3 MCObjectStreamer::EmitInstruction >> #4 ARMAsmPrinter::EmitInstruction >> <arm-mc-elf-s08.patch>_______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/ll...

...*Symbol, const MCExpr *Value); virtual void EmitWeakReference(MCSymbol *Alias, const MCSymbol *Symbol); virtual void EmitSymbolAttribute(MCSymbol *Symbol, MCSymbolAttr Attribute); @@ -108,6 +111,7 @@ public: private: virtual void EmitInstToFragment(const MCInst &Inst); virtual void EmitInstToData(const MCInst &Inst); + virtual void EmitMappingSymbol(bool IsData); void fixSymbolsInTLSFixups(const MCExpr *expr); @@ -119,6 +123,11 @@ private: std::vector<LocalCommon> LocalCommons; SmallPtrSet<MCSymbol *, 16> BindingExplicitlySet; + + // FIXME: This information is...

I have created a small ll file to reproduce the problem. I used the intrinsic function llvm.arm.space to introduce space between the beginning of the code and the jump table. If the first argument of llvm.arm.space is higher than INT_MAX ( *2147483647)*, then the bug is hit. Lower or equal to that value, it passes. It looks like a precision issue. Does this sound familiar to someone? ; ModuleID =

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

I was getting same error when i keep both EVEX/EVEX_4V and TA. So, i restored my original instructions and for that i have to include bool HasTA = TSFlags & X86II::TA; in x86MCCodeEmitter.cpp then used this condition; if(HasTA) ++SrcRegNum; in order to emit binary correctly. Is it right? On Tue, Sep 5, 2017 at 5:45 AM, Craig Topper <craig.topper at gmail.com> wrote: >