search for: mcdatafrag

Hello, I've been trying to add support to the integrated assembler to handle cases like below foo:instr; .if . - foo; instr; .endif when the dot symbol and foo are assigned to consecutive MCDataFragments <https://github.com/ClangBuiltLinux/linux/issues/744>. I have a patch <https://reviews.llvm.org/D6941> under review. And even though it seems to solve the problem, the concern is it complicates the code and we would like to know if there is more decent way to handle this. Please fe...

Hello and happy 2013, Would anyone object to renaming MCInstFragment to MCRelaxableFragment? I believe the latter expresses this class's purpose much more clearly and avoids the confusion with MCDataFragments which also contains instructions. Eli

...en, currently big endian support in the MC layer for ELF direct object generation is limited to ELF headers and tables like relocations. Text and data section contents are still generated as individual bytes. It looks as if the effort was started, but never completed. The proposal is to extend the MCDataFragment class to include a container of offset/size that one can traverse generating each element in the correct endianess: // Pseudo code for (iterator it = begin(), ie = end(); it != ie; ++it) { switch (it.getValueSize()) { default: assert(0 && "Invalid size!&quot...

Moving to LLVM dev to discuss the possibility of extending the cast infrastructure to handle this. On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: > On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >> TypeLoc casting looks bogus. >> >> TypeLoc derived types return true from classof when the dynamic type >>

...sion way earlier.. How would I emit things in different subsections? I can do a high level switch to .ARM.attributes, and if I were emitting one blob from begin to end, using the higher level interface would be preferable, but it contains additional subsections - which are naturally represented by MCDataFragments - Is there an MC equivalent of a SubSection (which is-a Section so I can switch back and forth?) Currently we only have stuff that go into the File subsection only, but.. for futureproofing? I pretty much duplicated style from MCELFObjectWriter.cpp, which does muck with MCDataFragments - (in...

...>(F); + const MCAlignFragment &AF = cast<MCAlignFragment>(F); uint64_t Count = FragmentSize / AF.getValueSize(); assert(AF.getValueSize() && "Invalid virtual align in concrete fragment!"); @@ -432,14 +432,14 @@ } case MCFragment::FT_Data: { - MCDataFragment &DF = cast<MCDataFragment>(F); + const MCDataFragment &DF = cast<MCDataFragment>(F); assert(FragmentSize == DF.getContents().size() && "Invalid size!"); OW->WriteBytes(DF.getContents().str()); break; } case MCFragment::FT_Fill:...

I guess that is OK, but wouldn't it be better to also rename MCDataFragments then? On 2 January 2013 12:25, Eli Bendersky <eliben at google.com> wrote: > Hello and happy 2013, > > Would anyone object to renaming MCInstFragment to MCRelaxableFragment? > I believe the latter expresses this class's purpose much more clearly > and avoids the confu...

On Thu, Jan 3, 2013 at 11:31 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I guess that is OK, but wouldn't it be better to also rename > MCDataFragments then? > I don't know what a more suitable name would be. Any ideas? Eli

...support in the MC layer for ELF > direct object generation is limited to ELF headers and tables like relocations. > Text and data section contents are still generated as individual bytes. > It looks as if the effort was started, but never completed. > > The proposal is to extend the MCDataFragment class to include a container > of offset/size that one can traverse generating each element in the correct > endianess: > > // Pseudo code > for (iterator it = begin(), ie = end(); it != ie; ++it) { > switch (it.getValueSize()) { > default: > assert(...

...port in the MC layer for ELF > direct object generation is limited to ELF headers and tables like relocations. > Text and data section contents are still generated as individual bytes. > It looks as if the effort was started, but never completed. > > The proposal is to extend the MCDataFragment class to include a container > of offset/size that one can traverse generating each element in the correct > endianess: > > // Pseudo code > for (iterator it = begin(), ie = end(); it != ie; ++it) { > switch (it.getValueSize()) { > default: > asse...

...SymbolData->Fragment = new MCFillFragment( > + 0, 0, Size, SectionData > + ); > + > + AddFragment(SymbolData->Fragment); > } > > // MCStreamer interface > > void WinCOFFStreamer::EmitLabel(MCSymbol *Symbol) { > + // FIXME: Who owns this memory? > + MCDataFragment *Fragment = new MCDataFragment(getSectionData()); There is no need to always create a new data fragment here; it is better to try and reuse the current fragment if possible. Take a look at MCMachOStreamer::EmitLabel for how I am doing this currently; I intend on moving some of the helper funct...

...Impl<MCFixup> &&Fixups); > > > > Note that this mirrors the fields > > MCEncodedFragmentWithContents::Contents and > > MCEncodedFragmentWithFixups::Fixups > > and the arguments could be directly moved into the fields of a newly > > created > > MCDataFragment. > > > > Would that work for your use case? > > > > Not quite, unfortunately - the issue is that we're doing a task that is > essentially "linking + a bit" - so imagine linking a bunch of files > together, the final, say, debug_info.dwo section is ma...

...SmallVectorImpl<MCFixup> &&Fixups); > > Note that this mirrors the fields > MCEncodedFragmentWithContents::Contents and > MCEncodedFragmentWithFixups::Fixups > and the arguments could be directly moved into the fields of a newly > created > MCDataFragment. > > Would that work for your use case? > Not quite, unfortunately - the issue is that we're doing a task that is essentially "linking + a bit" - so imagine linking a bunch of files together, the final, say, debug_info.dwo section is made up of the concatenation of all t...

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

...yer for ELF >> direct object generation is limited to ELF headers and tables like relocations. >> Text and data section contents are still generated as individual bytes. >> It looks as if the effort was started, but never completed. >> >> The proposal is to extend the MCDataFragment class to include a container >> of offset/size that one can traverse generating each element in the correct >> endianess: >> >> // Pseudo code >> for (iterator it = begin(), ie = end(); it != ie; ++it) { >> switch (it.getValueSize()) { >> def...

> I don't know what a more suitable name would be. Any ideas? I initially thought MCRelaxedFragment would go well with MCRelaxableFragment, since a MCRelaxableFragment is merged into a MCRelaxedFragment once we are done relaxing it. The problem is that both names are really similar. > Eli Cheers, Rafael

On Fri, Jul 16, 2010 at 11:25 AM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi Michael, > > Overall patch looks good. I do have a few comments below. My main > comment is please try to make the style match that used in the > MCMachOStreamer more closely. I intend to refactor more functionality > into the base MCObjectStreamer class, and having them use consistent >

...he job takes 20-30 minutes compiling from bitcode. When I looked into it I found that every single floating point number is loaded into ConstantFP object where the float is parsed into exponent, mantissa and stored in an integer part is stored in a heap allocated array, then these are emitted into MCDataFragments where again more heap allocated data, the float appears to be stored in SmallVectorImpl<char>. On top of this I see a lot of MCFillFragments added because of long double padding. All up the code I'm compiling ends up with 276 million MCFragments, which just take a super long time i...

...How would I emit things in different subsections? I can do a high > level switch to .ARM.attributes, and if I were emitting one blob from > begin to end, using the higher level interface would be preferable, > but it contains additional subsections - which are naturally > represented by MCDataFragments - Is there an MC equivalent of a > SubSection (which is-a Section so I can switch back and forth?) > Currently we only have stuff that go into the File subsection only, > but.. for futureproofing? We cross that bridge when we get there. It might be that the best thing to do is organi...

...Impl<char> &&Data, SmallVectorImpl<MCFixup> &&Fixups); Note that this mirrors the fields MCEncodedFragmentWithContents::Contents and MCEncodedFragmentWithFixups::Fixups and the arguments could be directly moved into the fields of a newly created MCDataFragment. Would that work for your use case? Peter On Mon, Feb 29, 2016 at 03:18:22PM -0800, David Blaikie via llvm-dev wrote: > Just in case it interests anyone else, I'm playing around with trying to > broaden the MCStreamer API to allow for emission of bytes without copying > the cont...