search for: mcasmbackend

...en hacking MC to convert these raw pointers (and worse: references!) to unique_ptrs (apologies to people whose backbends I've broken), but I hit a big blocker when I get to Target in "llvm/Support/TargetRegistry.h". Target vends MC objects by calling registered ctor functions. E.g.: MCAsmBackend *createMCAsmBackend(const MCRegisterInfo &MRI, StringRef TheTriple, StringRef CPU, const MCTargetOptions &Options) const { if (!MCAsmBackendCtorFn) return nullptr; return MCAsmBackendCtorFn(*this, MRI, Triple(TheTripl...

...to query MCTargetOptions. This is my plan: Make a path from the callers of Target::createAsmBackend to get MCTargetOptions to the MCELFObjectTargetWriter subclass or some method in the creation chain: <client, e.g. llvm-mc> -> Target::createAsmBackend(..., MCTargetOptions) -> (*MCAsmBackendCtorFn)(..., MCTargetOptions) -> <MCAsmBackend subclass constructor wanting options>(..., MCTargetOptions) adds MCTargetOptions to the MCAsmBackend subclass state or the bits needed <MCAsmBackend subclass wanting options>::createObjectWriter(...) -> create<foo&...

...arguments to function call, expected 3, have 4 MCOptions); ^~~~~~~~~ /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:401:3: note: 'createMCAsmBackend' declared here MCAsmBackend *createMCAsmBackend(const MCSubtargetInfo &STI, ^ 2 errors generated. Apparently, this has been broken for several months. I think I can fix this particular instance, but I was wondering whether anybody cares about this tool? -- Davide "There are no...

...e detected in lib/Target/* and lib/MC/*. In all cases the similar trick was detected as a leak (example from lib/Target/Sparc/MCTargetDesc/SparcMCTargetDesc.cpp) : static MCStreamer *createMCStreamer(const Target &T, StringRef TT, MCContext &Context, MCAsmBackend &MAB, raw_ostream &OS, MCCodeEmitter *Emitter, const MCSubtargetInfo &STI, bool RelaxAll, bool NoExecStack) { MCStreamer *S = createELFStreamer(Context, MAB, OS, Emit...

...new -target-abi option to TargetOptions struct that provides access to abi string. This info is stored in MCSubtarget class(ARMSubratget in this case) and distributed to other libraries. Unfortunately, for Mips we need this info in other classes that don't have access to MCSubtarget class, like MCAsmBackend and MCTargetStreamer and instantiating a new copy od TargetOption causes link errors as it is already instantiated in some drivers(llc.cpp for example). What would be the proper way to get the TargetOptions struct available in other classes? Kind regards, Vladimir -------------- next part ------...

Hi all, all ELF platforms at least and likely all others too allow something like the following: .text .asciz "arbitrary long string" .p2align 3 Depending on the size of the string, MCAsmBackend::writeNopData is called to pad text. For x86 and other backends with byte-sized instructions, this is no problem. Some backends like ARM and PPC flush explicitly to 16bit/32bit boundaries. There is an interested question on whether the non-instructions should be leading or trailing -- I think the b...

...). One of your commits on Monday (r227102) seems to make this a lot easier than it was looking last week when Vladimir and I were discussing this internally (I've been off sick so I only saw your commit last night). I haven't had chance to try this but I'm currently thinking that createMCAsmBackend() should have an LLVMTargetMachine* argument. The Mips-specific versions of this function can then get the ABI name from there and pass it down to createMipsELFObjectWriter(). From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eric Christopher Sent: 28 Januar...

...tion call, expected 3, have 4 > MCOptions); > ^~~~~~~~~ > /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:401:3: > note: 'createMCAsmBackend' declared here > MCAsmBackend *createMCAsmBackend(const MCSubtargetInfo &STI, > ^ > 2 errors generated. > > Apparently, this has been broken for several months. I think I can fix > this particular instance, but I was wondering whether anybody cares > about this tool?...

I am implementing a defined, but currently unimplemented by LLVM, ABI. This ABI differs from an existing ABI in its ELF object format by implementing a subset of an existing ABI, but encoded differently and by setting the e_ident EI_CLASS field. I am trying to use MCTargetOptions::getABIName to set a boolean in the modified subclass of MCELFObjectTargetWriter to indicate which relocation encoding

...Streamer? Thanks, Greg diff --git a/lib/MC/MCELFStreamer.cpp b/lib/MC/MCELFStreamer.cpp index 8107005..153ca78 100644 --- a/lib/MC/MCELFStreamer.cpp +++ b/lib/MC/MCELFStreamer.cpp @@ -40,12 +40,14 @@ class MCELFStreamer : public MCObjectStreamer { public: MCELFStreamer(MCContext &Context, MCAsmBackend &TAB, raw_ostream &OS, MCCodeEmitter *Emitter) - : MCObjectStreamer(Context, TAB, OS, Emitter) {} + : MCObjectStreamer(Context, TAB, OS, Emitter), + IsThumb(false), MappingSymbolCounter(0) {} MCELFStreamer(MCContext &Context, MCAsmBackend &TAB,...

...ted 3, have 4 >> MCOptions); >> ^~~~~~~~~ >> /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:401:3: >> note: 'createMCAsmBackend' declared here >> MCAsmBackend *createMCAsmBackend(const MCSubtargetInfo &STI, >> ^ >> 2 errors generated. >> >> Apparently, this has been broken for several months. I think I can fix >> this particular instance, but I was wondering whether anybody care...

...y the object/container type. ELF is usually taken as "default" when no other option is chosen. A representative example from X86MCTargetDesc.cpp: --------------- static MCStreamer *createMCStreamer(const Target &T, StringRef TT, MCContext &Ctx, MCAsmBackend &MAB, raw_ostream &_OS, MCCodeEmitter *_Emitter, bool RelaxAll, bool NoExecStack) { Triple TheTriple(TT); if (TheTriple.isOSDarwin() || TheTri...

...). One of your commits on Monday (r227102) seems to make this a lot easier than it was looking last week when Vladimir and I were discussing this internally (I've been off sick so I only saw your commit last night). I haven't had chance to try this but I'm currently thinking that createMCAsmBackend() should have an LLVMTargetMachine* argument. The Mips-specific versions of this function can then get the ABI name from there and pass it down to createMipsELFObjectWriter(). From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eric Christopher Sent: 28 Januar...

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

Hello, We're currently working on MC-JIT, focusing on runtime generation and loading of ELF object files, even on non-ELF platforms (i.e. Windows). However, we run into a problem with MC insisting to generate COFF objects on Windows, MachO on Macs and ELF only otherwise, based on the triple. Is there an existing method to generate ELF objects with MC on Windows, without modifying MC? Thanks

...y the object/container type. ELF is usually taken as "default" when no other option is chosen. A representative example from X86MCTargetDesc.cpp: --------------- static MCStreamer *createMCStreamer(const Target &T, StringRef TT, MCContext &Ctx, MCAsmBackend &MAB, raw_ostream &_OS, MCCodeEmitter *_Emitter, bool RelaxAll, bool NoExecStack) { Triple TheTriple(TT); if (TheTriple.isOSDarwin() || TheTri...

...upportsSeeking()) { BOS = make_unique<buffer_ostream>(Out->os()); OS = BOS.get(); } This also seems to do OK. Now I would think I can finally get around to making the code emitter and the MCStreamer: MCCodeEmitter *CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx); MCAsmBackend *MAB = TheTarget->createMCAsmBackend(*MRI, TripleName, MCPU); MCStreamer *Str = TheTarget->createMCObjectStreamer(TheTriple, Ctx, *MAB, *OS, CE, *STI, true, false); So, like, wow, I would think I should be good to go here! I should be able to just use functions like: Str->EmitIns...

this patch removes some redundant includes in llvm-mc.cpp thanks, Jun --- llvm-3.2.src/tools/llvm-mc.org/llvm-mc.cpp +++ llvm-3.2.src/tools/llvm-mc/llvm-mc.cpp @@ -17,7 +17,6 @@ #include "llvm/MC/MCAsmBackend.h" #include "llvm/MC/MCAsmInfo.h" #include "llvm/MC/MCContext.h" -#include "llvm/MC/MCCodeEmitter.h" #include "llvm/MC/MCInstPrinter.h" #include "llvm/MC/MCInstrInfo.h" #include "llvm/MC/MCObjectFileInfo.h" @@ -26,7 +25,6 @@ #in...

With the MIPS compiler, when we have static constants, in the .s file we get something like: .type $.str33, at object # @.str33 .section .rodata.str1.1,"aMS", at progbits,1 $.str33: .asciz "//" .size $.str33, 3 Currently when we create direct object code we are referencing the symbol as an offset in .rodata and not directly using

I am having an issue with MCJIT on the ppc64 machine architecture. The symptom is that for a particular IR function the target machine won't emit neither an object nor an assembly file and subsequent calling the pointer to function results in a segfault. My application generates on the fly several functions with the builder and executes them with the MCJIT engine. I came across this