search for: mcsectionxxx

...gt; 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? I'm enclosing my patch for reforming MCSectionCOFF to match the implementation strategy of the other two MCSection classes. You may find it useful as a starting point. It see...

...ction 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? > > I'm enclosing my patch for reforming MCSectionCOFF to match the > implementation strategy of the other two MCSection classes. You may find > it useful as...

...ction 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? > > I'm enclosing my patch for reforming MCSectionCOFF to match the > implementation strategy of the other two MCSection classes. You may find > it useful as...

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

...hat 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? >> >> I'm enclosing my patch for reforming MCSectionCOFF to match the >> implementation strategy of the other two MCSection classes. You may find &g...

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

...r 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? >>> >>> I'm enclosing my patch for reforming MCSectionCOFF to match the >>> implementation strategy of the other two MCSection classes....

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

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