llvm dev - May 2010 - [LLVMdev] MCStreamer itnerface

This is a brain-dump of my thoughts on the MCStreamer interface
after several
days of digging around trying to get a COFF writer working.

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.

Section assignment should be the responsiblity of the object imlementing the
MCStreamer interface, with the caller givin the ability to give hints as to
what section to place the symbol into.

instead of SwitchSection, there would be BeginSymbol, and SymbolSymbol, it
would
be illegal to call any EmitXXX function outside of these two calls

BeginSymbol(Symbol, SectionHint)
  EmitAttribute(...)
  EmitAttribute(...)
  ...
StartFragmentEmission()
  EmitFragment(...)
  EmitFragment(...)
  ...
EndSymbol()

Object file writers would typically start recording fragments and attributes
for
a symbol on the BeginSymbol, then at EndSymbol they would evaluate what was
streamed, and decide what section the symbol should be placed in.

Assembly writers could with some state data emit assemble as emission calls
are
made. Assembler parsers could use 'section symbols' to provide section
level
attributes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100504/5cedc774/attachment.html>

On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote:
> This is a brain-dump of my thoughts on the MCStreamer interface after
several
> days of digging around trying to get a COFF writer working.
Great!  Something that is worth pointing out is that the MCStreamer API is
intended to directly reflect what is happening in .s files.  We basically want
one MCStreamer callback to correspond to one statement in the .s file.  This
makes it easier to handle from the compiler standpoint, but is also very
important for the llvm-mc assembly parser itself.
> 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.
> Section assignment should be the responsiblity of the object imlementing
the
> MCStreamer interface, with the caller givin the ability to give hints as to
> what section to place the symbol into.
Section assignment really needs to happen at a higher level.  The
TargetLoweringObjectFile interfaces are the ones responsible for mapping a
global/function -> section.  This interface (not mcstreamer) should handle
this.

The important point here is that the COFF MCSection needs to have the right
level of semantic information.  In fact, MCSection is the place that I'd
start for COFF bringup.
> instead of SwitchSection, there would be BeginSymbol, and SymbolSymbol, it
would
> be illegal to call any EmitXXX function outside of these two calls
> 
> BeginSymbol(Symbol, SectionHint)
>   EmitAttribute(...)
>   EmitAttribute(...)
>   ...
> StartFragmentEmission()
>   EmitFragment(...)
>   EmitFragment(...)
>   ...
> EndSymbol()
> 
> Object file writers would typically start recording fragments and
attributes for
> a symbol on the BeginSymbol, then at EndSymbol they would evaluate what was
> streamed, and decide what section the symbol should be placed in.
Why do you need this?  This concept doesn't exist in the .s file, so I
don't think that MCStreamer is the right level for this.

-Chris

On Wed, May 5, 2010 at 11:15 AM, Chris Lattner <clattner at apple.com>
wrote:
> On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote:
> ...  We basically want one MCStreamer callback to correspond to one
> statement in the .s file.  This makes it easier to handle from the compiler
> standpoint, but is also very important for the llvm-mc assembly parser
> itself.
>
> This is an assumption I question. From an evolutionary perspective I agree;
Given the existing code base I do see this as a logical transformation. As
far as the assembly parser/streamer is concerned it certainly
simplifies their implementations. But I also think that this interface could
evolve in a direction that simplifies the common case (compiler -> object
file) at a small expense to handling assembly language files.
> 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)
> Section assignment should be the responsiblity of the object imlementing
> the
> > MCStreamer interface, with the caller givin the ability to give hints
as
> to
> > what section to place the symbol into.
>
> Section assignment really needs to happen at a higher level.  The
> TargetLoweringObjectFile interfaces are the ones responsible for mapping a
> global/function -> section.  This interface (not mcstreamer) should
handle
> this.
>
> The important point here is that the COFF MCSection needs to have the right
> level of semantic information.  In fact, MCSection is the place that
I'd
> start for COFF bringup.
>
> OK, I see that now. The current isolation between TargetLoweringObjectFile
-> MCStreamer -> MCObjectWriter has proven somewhat problematic, mostly
due
to my lack of understanding. I guess MCSectionXXX was meant to provide
communication between them. Should the same be true of MCSymbol, and their
data counterparts?

> > instead of SwitchSection, there would be BeginSymbol, and
SymbolSymbol,
> it would
> > be illegal to call any EmitXXX function outside of these two calls
> >
> > BeginSymbol(Symbol, SectionHint)
> >   EmitAttribute(...)
> >   EmitAttribute(...)
> >   ...
> > StartFragmentEmission()
> >   EmitFragment(...)
> >   EmitFragment(...)
> >   ...
> > EndSymbol()
> >
> > Object file writers would typically start recording fragments and
> attributes for
> > a symbol on the BeginSymbol, then at EndSymbol they would evaluate
what
> was
> > streamed, and decide what section the symbol should be placed in.
>
> Why do you need this?  This concept doesn't exist in the .s file, so I
> don't think that MCStreamer is the right level for this.


I realize that my expectations of the MCStreamer interface are not quite the
same as the intentions behind its design. It seemed to be that having these
calls with the restrictions on when they would be allowed would simplify an
object file writers job sifting though the incoming data and organizing into
what will become the output file.

I had a problem with MCStreamer::EmitCommonSymbol
& MCStreamer::EmitLocalCommonSymbol. When I implemented them I assumed this
meant to put those symbols into the .bss segment. This required me to get a
hold of the TLOF from the streamer. I now realize this is wrong after
re-reading the description of the '.comm' directive a few times.  I am
not
sure why an uninitialized global variable was being emitted using this, that
seems wrong since global variables in different compilation units with the
same name would get merged together at link time. (this is using clang on a
C source file)

Thanks for taking the time to read and respond to my post. I think I need to
get better acquainted with these components.

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