search for: mcstreamer

On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > This is a brain-dump of my thoughts on the MCStreamer interface after several > days of digging around trying to get a COFF writer working. Great! Something that is worth pointing out is that the MCStreamer API is intended to directly reflect what is happening in .s files. We basically want one MCStreamer callback to correspond to one statement...

This is a brain-dump of my thoughts on the MCStreamer interface after several days of digging around trying to get a COFF writer working. All fragments should be associated with a symbol. For assembler components, a unnammed "virtual" symbol can be used when there is no explicit label defined. Section assignment should be the responsiblity...

On Wed, May 5, 2010 at 11:15 AM, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one > statement in the .s file. This makes it easier to handle from the compiler > standpoint, but is also very important for the llvm-mc assembly parser > itself. > > This is an assumption I question. From an evolutionary perspective I agree; Given the exi...

I compile these two lines in llc @tst1 = internal global [4 x i8] zeroinitializer; @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; @tst1 is emited via MCStreamer::EmitCommonSymbol while the other is emited via MCStreamer::EmitLabel followed by MCStreamer::EmitBytes from what I can tell, only symbols with common linkage should me emitted by MCStreamer::EmitCommonSymbol, is this the expected behavior or should I fix it? -------------- next part ------------...

On May 5, 2010, at 1:22 PM, Nathan Jeffords wrote: > On Wed, May 5, 2010 at 11:15 AM, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one statement in the .s file. This makes it easier to handle from the compiler standpoint, but is also very important for the llvm-mc assembly parser itself. > > This is an assumption I question. From an evolutionary perspective I agree; Given the existing code bas...

...e number of tests break. Did I misunderstand how > parseIdentifier() is meant to be used? Am I atleast passing this > Simple bool around correctly, and appending " simple" in the low asm > layer appropriately? What am I missing? > > Thanks. > > include/llvm/MC/MCStreamer.h | 2 +- > lib/CodeGen/AsmPrinter/DwarfCFIException.cpp | 2 +- > lib/MC/MCAsmStreamer.cpp | 6 ++++-- > lib/MC/MCParser/AsmParser.cpp | 8 ++++++-- > lib/MC/MCStreamer.cpp | 2 +- > test/MC/AsmParser/cfi-star...

...s that I have trouble with / currently need to implement. -- I've been starting by taking the source code from the "llvm-mc" tool, and working that down into a smaller form that does the kinds of things I want to do at the MC "layer". So, I'd like to be able to use a MCStreamer object directly to make some output file, and object ".o" would be just fine to start with. I seem to be able to create an aarch64 target without too much issue: llvm::InitializeAllTargetInfos(); llvm::InitializeAllTargetMCs(); llvm::InitializeAllAsmParsers(); llvm::InitializeAl...

Just in case it interests anyone else, I'm playing around with trying to broaden the MCStreamer API to allow for emission of bytes without copying the contents into a local buffer first (either because you already have a buffer, or the bytes are already present in another file, etc) in http://reviews.llvm.org/D17694 . In theory there's some overlap with lld here (no doubt it already does...

> > > The logic to handle this has to go somewhere, putting it in the MCStreamer > *implementation* that needs it is the most logical place. We also aim to > implement an assembler, it doesn't make sense to duplicate this logic in the > compiler and the assembler parser. > > Assembly language has often been *the* intermediate form for between compilers and o...

...teLeaks over LLVM codebase to detect false-positives and at the same time eliminate memory leaks. The majority of leaks were 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 Rela...

...> lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. > > We also need to sort out COFF TLOF, and get rid of the directive stuff. > > > It looks to me that you should have an Emit method for the .scl, .def, > .type, .endef directives. One callback each. > There is already a MCStreamer::EmitZerofill() is seems to be MachO specific ? 'MCStreamer::EmitCOFFStabs()' ? 'MCStreamer:: EmitASCII()' ? Shall I do these as two separate patches ? Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-...

On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com> wrote: > > On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Just in case it interests anyone else, I'm playing around with trying to > broaden the MCStreamer API to allow for emission of bytes without copying > the contents into a local buffer first (either because you already have a > buffer, or the bytes are already present in another file, etc) in > http://reviews.llvm.org/D17694 . In theory there's some overlap with lld > here (no do...

...; >> New method of emitting object code is ok for me. But it is still >> experimental, isn't it? > > Yes. Thank you for answers! Now there is a way to implement what I'd like to. But it would be MUCH better if LLVMTargetMachine::addPassesToEmitFile could take arbitrary MCStreamer as input. Without such a feature when compiling bytecode (i.e. emulating llc -filetype=obj behaviour) I have to emit .s file first, disassemble it and feed to custom MCStreamer. That'll hopely work but it's ugly. -- Best Regards Peter Shugalev

...rtant point here is that the COFF MCSection needs to > have the right level of semantic information. In fact, > MCSection is the place that I'd start for COFF bringup. > > OK, I see that now. The current isolation > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > proven somewhat problematic, mostly due to my lack of understanding. > I guess MCSectionXXX was meant to provide communication between them. > Should the same be true of MCSymbol, and their data counterparts? I'm enclosing my patch for reforming MCSectionCOF...

...for me. But it is still >>>> experimental, isn't it? >>> Yes. >> Thank you for answers! >> >> Now there is a way to implement what I'd like to. But it would be MUCH >> better if LLVMTargetMachine::addPassesToEmitFile could take arbitrary >> MCStreamer as input. Without such a feature when compiling bytecode >> (i.e. emulating llc -filetype=obj behaviour) I have to emit .s file >> first, disassemble it and feed to custom MCStreamer. That'll hopely work >> but it's ugly. > > What are you trying to do? I don't...

...code is ok for me. But it is still >>> experimental, isn't it? >> >> Yes. > > Thank you for answers! > > Now there is a way to implement what I'd like to. But it would be MUCH > better if LLVMTargetMachine::addPassesToEmitFile could take arbitrary > MCStreamer as input. Without such a feature when compiling bytecode > (i.e. emulating llc -filetype=obj behaviour) I have to emit .s file > first, disassemble it and feed to custom MCStreamer. That'll hopely work > but it's ugly. What are you trying to do? I don't see why you'd have...

...is that the COFF MCSection needs to > > have the right level of semantic information. In fact, > > MCSection is the place that I'd start for COFF bringup. > > > > OK, I see that now. The current isolation > > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > > proven somewhat problematic, mostly due to my lack of understanding. > > I guess MCSectionXXX was meant to provide communication between them. > > Should the same be true of MCSymbol, and their data counterparts? > > I'm enclosing my patch fo...

...; wrote: > > On May 6, 2010, at 10:01 PM, Nathan Jeffords wrote: > > > I compile these two lines in llc > > > > @tst1 = internal global [4 x i8] zeroinitializer; > > @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; > > > > @tst1 is emited via MCStreamer::EmitCommonSymbol > > while the other is emited via MCStreamer::EmitLabel followed by MCStreamer::EmitBytes > > > > from what I can tell, only symbols with common linkage should me emitted by MCStreamer::EmitCommonSymbol, > > > > is this the expected behavior or should...

Hi! I'd like to emit code to a custom MCStreamer instead of e.g. MCELFStreamer. Unfortunately LLVMTargetMachine::addCommonCodeGenPasses is private but I would need it, or even better a method simular to addPassesToEmitFile (e.g. addPassesToEmitCustomMC) taking an MCSreamer would be great. What do you think? -Jochen