search for: mcstreamers

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

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 of the object imlementing the MCStreamer

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

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

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

Really sorry I missed this. Just found it looking for something else in my inbox. I think we should support this but * We should still err on other identifiers ".cfi_startport bar" is invalid. * If I read the gas documentation correctly, the effect of "simple" is to skip the initial cfi instructions. We should test if that is the case and implement it too. Accepting and

llvm-dev, Thanks so much in advance for any help, tips, or advice you may be able to offer me. I'm going to try to avoid the big-picture description of the project I'm working on, and only talk about the parts 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

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 object

Hi, I've run Clang Static Analyzer checker alpha.cplusplus.NewDeleteLeaks 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

On 7 May 2010 18:14, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 10:02 AM, Aaron Gray wrote: > > On 7 May 2010 17:53, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> >> This seems counter intuitive to me, I can understand that C assigned that >>> behavior

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

Chris Lattner wrote: > On Mar 27, 2010, at 11:56 AM, Peter Shugalev wrote: > >>>> What exactly is expected to be coming? Will it be the same way MachO is >>>> currently implemented but with some flexibility to supply my own class >>>> to do actual object output? Or just a return of old ObjectCodeEmitter? >>> We're integrating a full assembler

On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > > The important 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 ->

Chris Lattner wrote: > On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: > >>>> 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

On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >>> >>> 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

Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit it. I was just pondering how to deal with the

On May 7, 2010, at 12:39 AM, Nathan Jeffords wrote: > On Fri, May 7, 2010 at 12:03 AM, Chris Lattner <clattner at apple.com> 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]; >

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