[LLVMdev] MCStreamer interface

[Nathan Jeffords]

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

struct MCAssemblyDataFactory {
  virtual MCSymbolData * createSectionData (MCSection* Symbol) = 0;
  virtual MCSymbolData * createSymbolData (MCSymbol* Symbol) = 0;
};

which would then me given to the assembler when created.

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.

template <value_type> void setSectionData (MCSection const * Section,
value_type const & Value);
template <value_type> bool getSectionData (MCSection const * Section,
value_type & Value) const;

template <value_type> void setSymbolData (MCSymbol const * Symbol,
value_type const & Value);
template <value_type> bool getSymbolData (MCSymbol const * Symbol,
value_type & Value) const;

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.

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

Hopefully, I will have something people can look at pretty soon here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100507/b16cc2fd/attachment.html>