similar to: [LLVMdev] MCStreamer itnerface

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

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 should probably elaborate on why I feel the interface should be as such. It seems to be the common case is compiler outputting to object files. In this case, all fragments are associated with symbols. What section the fragments go into is generally irrelevant to the compiler, except in special cases like global variable constructor/destructor lists and the like. At code generation time, 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

> > > 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

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

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 ->

On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > 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

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 5, 2010, at 5:22 PM, Nathan Jeffords wrote: > > 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

On Fri, May 7, 2010 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > > 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 >

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

On 7 May 2010 08:15, Nathan Jeffords <blunted2night at gmail.com> wrote: > > > On Fri, May 7, 2010 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: >> >> Thanks! Funny, I was just preparing a patch to submit for my changes to >> MCSectionCOFF. My changes look to be fairly

Somewhere I had got it in my head that global variables had static storage class by default. I guess I was wrong. On May 5, 2010 2:45 PM, "Dale Johannesen" <dalej at apple.com> wrote: On May 5, 2010, at 2:32 PMPDT, Nathan Jeffords wrote: >> >> Global definitions like "int x;" are t... Technically yes; the original K&R C book had the one-definition rule

> > > Global definitions like "int x;" are treated as common to allow > linking buggy programs that forget to use "extern" on declarations. Is this always the behavior, or only when certain options are set? This seems like a violation of the language standard. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Wed, May 5, 2010 at 1:22 PM, Nathan Jeffords <blunted2night at gmail.com> wrote: > I had a problem with MCStreamer::EmitCommonSymbol > & MCStreamer::EmitLocalCommonSymbol. When I implemented them I assumed this > meant to put those symbols into the .bss segment. This required me to get a > hold of the TLOF from the streamer. I now realize this is wrong after >

Re having all fragments associated with some symbol -- this makes sense if you think in high level terms and assume all symbols to be some "objects". All data (fragments) you want to output is associated with some "object" (symbol). However, that's probably too high level thinking for MC interface. High level objects might not directly correspond to object-file level

On Fri, Feb 25, 2011 at 12:16 PM, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote: > On Thursday 03 February 2011 14:14:28 Renato Golin wrote: >> On 3 February 2011 10:25, Siarhei Siamashka <siarhei.siamashka at gmail.com> > wrote: >> > I have submitted a bug some time ago to LLVM bugtracker: >> > http://llvm.org/bugs/show_bug.cgi?id=8931 >>

On Wed, May 5, 2010 at 5:53 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: >> >> 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