search for: mcobjectstream

I need to sub-class MCObjectStreamer to account for some of our target-specific requirements, and it wasn't apparent to me how to register my version after reviewing and stepping through code. How do I wire up LLVM to use my sub-classed implementation instead of the default? Thanks, - -- Mario Guerra mariog at codeaurora.org...

...l Dunbar <daniel at zuster.org> wrote: > Hi Michael, > > Overall patch looks good. I do have a few comments below. My main > comment is please try to make the style match that used in the > MCMachOStreamer more closely. I intend to refactor more functionality > into the base MCObjectStreamer class, and having them use consistent > idioms makes this easier; specific instances are included in the > comments: I implemented the changes and merged some stuff into MCObjectStreamer along with marking all the functions that are basically the same. http://github.com/Bigcheese/llvm-mir...

Hi All, While trying to put together an MC-based assembler the other day, I again encountered MC's non-obvious memory ownership rules. The most egregious example of these is MCObjectStreamer's destructor: MCObjectStreamer::~MCObjectStreamer() { delete &Assembler->getBackend(); delete &Assembler->getEmitter(); delete &Assembler->getWriter(); delete Assembler; } In the depths of a fever from a head-cold, I snapped. I've been hacking MC to convert...

...comments and offer some pointers on how to get this code out of MCELFStreamer? 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) {}...

...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::EmitAndCountInstruction(llvm::MCInst&) lib/Target/X86/X86MCInstLower.cpp:106:3 #13 0x00000000007a32dc llvm::X86AsmPrinter::EmitInstruction(...

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

Figured it out If I have an MCObjectStreamer object and the MCSection object of the section in question all I need to do is MCObjectStreamer & MCOS = static_cast <MCObjectStreamer &>(OutStreamer); MCSectionData &SD = MCOS.getAssembler().getOrCreateSectionData(*Section); SD.setAlignment(4); Jack ------------...

Hi Michael, Overall patch looks good. I do have a few comments below. My main comment is please try to make the style match that used in the MCMachOStreamer more closely. I intend to refactor more functionality into the base MCObjectStreamer class, and having them use consistent idioms makes this easier; specific instances are included in the comments: -- > diff --git a/lib/MC/WinCOFFStreamer.cpp b/lib/MC/WinCOFFStreamer.cpp > index 1030cdb..079a813 100644 > --- a/lib/MC/WinCOFFStreamer.cpp > +++ b/lib/MC/WinCOFFStreamer....

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

...a lack of iterator support. Have we overlooked this functionality? If not, does it make sense for us to add it? Those issues aside, it sounds like the streamer already understands how to process and print sub-instructions, which is good. Will the size of the packet be properly accounted for by the MCObjectStreamer if we have to pad the packet (mainly for fetch alignment)? Thanks, - -- Mario Guerra mariog at codeaurora.org Qualcomm Innovation Center Inc is a member of Code Aurora Forum, hosted by The Linux Foundation

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+0...

...Gen/MachineBasicBlock.h" > #include "llvm/CodeGen/MachineInstr.h" > #include "llvm/IR/Constants.h" > +#include "llvm/MC/MCCodeEmitter.h" > #include "llvm/MC/MCExpr.h" > #include "llvm/MC/MCInst.h" > +#include "llvm/MC/MCObjectStreamer.h" > #include "llvm/MC/MCStreamer.h" > #include "llvm/Support/ErrorHandling.h" > +#include "llvm/Support/Format.h" > +#include <algorithm> > > using namespace llvm; > > @@ -69,10 +74,7 @@ > MachineBasicBlock::const_in...

Owen, On 11/29/12 18:16, Owen Anderson wrote: >> Will the size of the >> packet be properly accounted for by the MCObjectStreamer if we have to pad >> the packet (mainly for fetch alignment)? > The MC system (including relaxation) is capable of handling instructions with variable length encodings whose size can't be determined until the MCCodeEmitter step. Where could I find more information about how this is h...

...FStreamer came up, you both were helpful in identifying ways to handle the use case without requiring subclassing. Can you please take a look at the context below and let me know if you have any suggestions? For reference, this was posted to the list yesterday under the subject "sub-classing MCObjectStreamer?": > Okay, after more careful scrutiny of the code I see that MCObjectStreamer is > intended to be very generic and it would actually be MCELFStreamer that I would > need to subclass. I see from a search through the dev list that this was discussed > previously and discouraged,...

...The streamer knows nothing at all about sub-instructions. It's the responsibility of the printInstruction/encodeInstruction methods in your printer or decoder know that they need to recurse onto the contents of the bundle. > Will the size of the > packet be properly accounted for by the MCObjectStreamer if we have to pad > the packet (mainly for fetch alignment)? The MC system (including relaxation) is capable of handling instructions with variable length encodings whose size can't be determined until the MCCodeEmitter step. --Owen

Hi, This patch adds R600/SI disassembly text to compiled object files, when a code dump is requested, to assist debugging in Mesa clients. Here's an example of the output in a Mesa client with a corresponding patch and RADEON_DUMP_SHADERS set: Shader Disassembly: S_WQM_B64 EXEC, EXEC ; BEFE0A7E S_MOV_B32 M0, SGPR6 ; BEFC0306

...want to start this, I would recommend just trying to write the JITObjectWriter (and matching MCJITStreamer), and see where it goes. You can clone most of the Mach-O streamer for use by the JITStreamer, and gut the obviously unneeded parts. Once we have something working, we can factor out a common MCObjectStreamer class. I have been meaning to do this, but won't have time for a couple weeks I suspect. - Daniel On Apr 15, 2010, at 1:40 PM, Chris Lattner wrote: > > On Apr 11, 2010, at 10:35 AM, Olivier Meurant wrote: > >> Hi Chris, >> >> Thanks for taking time to communi...

...inaryCodeForInst 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/llvm-commits > >

...k, I'm not 100% up on how MIPS represents jump tables, so take with a grain of salt and all that. Normally how this stuff works is that the streamer will create Fixups (MCDataFragment::addFixup()) for anything that might require a relocation. That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example). Then the object streamer resolves those fixups, directly if it can or via relocations otherwise via the MCObjectWriter::RecordRelocation() hook. For MachO, that's bee...

...I would > recommend just trying to write the JITObjectWriter (and matching > MCJITStreamer), and see where it goes. You can clone most of the Mach-O > streamer for use by the JITStreamer, and gut the obviously unneeded parts. > Once we have something working, we can factor out a common MCObjectStreamer > class. I have been meaning to do this, but won't have time for a couple > weeks I suspect. > > - Daniel > > On Apr 15, 2010, at 1:40 PM, Chris Lattner wrote: > > > > > On Apr 11, 2010, at 10:35 AM, Olivier Meurant wrote: > > > >> Hi Chris, &g...