<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><div><br></div></div></div></div></blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div>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.</div>
<div class="im"><div><br></div></div></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><div></div><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">> All fragments should be associated with a symbol. For assembler components, a<br>

> unnammed "virtual" symbol can be used when there is no explicit label defined.<br>
<br>
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.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br></div></blockquote><div>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)</div>
</div></blockquote><div><br></div></div><div>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.</div>
<div class="im"><br></div></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div>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.</div>
<div class="im"><div><br></div><blockquote type="cite"><div><div><div></div></div></div></blockquote></div></div></div></blockquote><div>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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div>As others have pointed out, this is one of the many horrors of C :)</div>
<div><br></div></div></blockquote><div><br></div><div>Another reason why I am attempting to develop my own language. :)</div><div><br></div><div>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?</div>
<div><br></div><div>- Nathan</div><div><br></div></div>