[LLVMdev] MCStreamer interface

[Daniel Dunbar]

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

The reason for MCSectionCOFF etc., is that they are shared between the
MC and CodeGen interfaces. They have semantics that apply to both .s
files and object files, and even the frontend has some interest in
them.

OTOH, things like MCSymbolData, MCSectionData, are private to the
assembler backend, and so only the assembler and object writer need to
know about them (they are unused when writing to a .s file, for
example).

MCAssembler already maintains its own association of these data
structures, and there are a few bits available for the object file
backends inside MCSymbolData. I would be fine adding a few more for
use by specific object writers, if it simplifies your implementation.

I'm sorry I have had time to be very present on this thread, but
please feel free to mail me / ping me if there is a something about
the assembler backend you have questions on. I'm very excited to see
COFF support coming up!

 - Daniel

>> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>