[LLVMdev] MCStreamer interface

[Chris Lattner]

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 form for between compilers and object files/executables, but I don't think its the most effective form. That said I have limited experience writing code generators so my opinions do not bear the wisdom of you and other developers of this library on this topic.

I completely agree, but it is a very important and effective form of communication :)

One nice fallout of the MCStreamer design is that once the COFF writer is available, we'll have a stand-alone coff assembler mostly "for free".  In fact, developing this as a coff assembler (which can be accessed with 'llvm-mc foo.s -o foo.obj -filetype=obj') is easier in a lot of ways than dealing with the compiler!

> 
> Yes somewhat.  Currently, the COFF implementation of the assembler backend should maintain a DenseMap from MCSymbol* to whatever data you need to associate with a symbol.  This is equivalent to embedding per-symbol stuff in the MCSymbol itself.  MCSection should be subclassed and you should put COFF specific stuff in MCSectionCOFF.
> 
>> 
> 
> I think this is an important detail I was missing. I can already see how this will help with COMDAT sections. Is there any reason for the difference between symbol and section in this respect?

You'd have to ask Daniel about this.  I don't recall if this is a short term thing that he'd like to fix or if this is an important design decision.

> 
> As others have pointed out, this is one of the many horrors of C :)
> 
> 
> Another reason why I am attempting to develop my own language. :)
> 
> p.s. I posted my coff backend patch to llvm-commit, but that apears to be the wrong place, where should I have posted it?

llvm-commits is a great place for it!

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100505/b3168959/attachment.html>