[LLVMdev] MCStreamer interface

[Nathan Jeffords]

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

> 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.
>>
>> What do you mean by fragment?  Can you give me an analogy with what the
>> syntax looks like in a .s file, I'm not sure exactly what you mean here.
>
>
>> I use the term fragment to refer to the MCFragment class and
> its derivatives. I understand that to mean any entity representing data in
> the final linked and loaded form. (something with an address)
>
>
> Ok, MCFragment should definitely be formed behind the MCStreamer
> implementation.  The .s printing implementation of MCStreamer, for example,
> has no use for it.  With the current design, it would be a layering
> violation to make it earlier.
>
>
I agree with this completely, I quite like that aspect of the design: The
streamer putting fragments into sections and allowing the assembler to
combine it all resolving fix-ups when it can, letting the writer deal those
it can't.


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

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?

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