<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5"><br>
</div></div>The reason for MCSectionCOFF etc., is that they are shared between the<br>
MC and CodeGen interfaces. They have semantics that apply to both .s<br>
files and object files, and even the frontend has some interest in<br>
them.<br>
<br>
OTOH, things like MCSymbolData, MCSectionData, are private to the<br>
assembler backend, and so only the assembler and object writer need to<br>
know about them (they are unused when writing to a .s file, for<br>
example).<br>
<br>
MCAssembler already maintains its own association of these data<br>
structures, and there are a few bits available for the object file<br>
backends inside MCSymbolData. I would be fine adding a few more for<br>
use by specific object writers, if it simplifies your implementation.<br>
<br></blockquote><div><br></div><div>would it make sense to allow the object file streamer/writer code to provide custom derivations of MCSymbolData/MCSectionData so that its is free to define and interpret that data without other object file formats being aware of it? something like</div>
<div><br></div><div>struct MCAssemblyDataFactory {</div><div>  virtual MCSymbolData * createSectionData (MCSection* Symbol) = 0;</div><div>  virtual MCSymbolData * createSymbolData (MCSymbol* Symbol) = 0;</div><div>};</div>
<div><br></div><div>which would then me given to the assembler when created.</div><div><br></div><div>I had started down a different road, that if acceptable, might provide a more general solution. I have added some API's to MCContext to allow me to associate arbitrary data with section's & symbol's.</div>
<div><br></div><div>template <value_type> void setSectionData (MCSection const * Section, value_type const & Value);</div><div>template <value_type> bool getSectionData (MCSection const * Section, value_type & Value) const;</div>
<div><br></div><div><div>template <value_type> void setSymbolData (MCSymbol const * Symbol, value_type const & Value);</div><div>template <value_type> bool getSymbolData (MCSymbol const * Symbol, value_type & Value) const;</div>
<div> </div><div>I can implement these with in a completely type safe manner without using virtual functions or virtual function tables and no dynamic runtime type information. With some extra work, they can use a single allocation per data item, currently their is two. I do rely on the typeid to return a typeinfo object for value_type, but I do this at compile time, not runtime.</div>
<div><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'm sorry I have had time to be very present on this thread, but<br>
please feel free to mail me / ping me if there is a something about<br>
the assembler backend you have questions on. I'm very excited to see<br>
COFF support coming up!<font class="Apple-style-span" color="#888888"><br></font></blockquote><div> </div><div>Hopefully, I will have something people can look at pretty soon here.</div><div><br></div></div>