<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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></blockquote><div><br></div><div>I completely agree, but it is a very important and effective form of communication :)</div><div><br></div><div>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!</div><div><br></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; position: static; z-index: auto; "><div style="word-wrap:break-word"><div><div><font class="Apple-style-span" color="#000000"><br></font></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></blockquote><div><br></div><div>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.</div><br><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; position: static; z-index: auto; "><div style="word-wrap:break-word"><div><br>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></blockquote><br></div><div>llvm-commits is a great place for it!</div><div><br></div><div>-Chris</div><br></body></html>