search for: mcdatafragments

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

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

Proposal for ELF text and data big endian support for direct object generation Unless I am mistaken, 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

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

On Thu, Nov 29, 2012 at 3:49 PM, David Blaikie <dblaikie at gmail.com> wrote: > 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

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

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

Jim, I see routines that are already available to do the endianizing, but the data and text section contents don't have sizing for the individual elements as far as I can see so that I can endianize them. That is the part I am trying to solve, not the bit twiddling algorithm. Did I miss something? Jack ________________________________________ From: Jim Grosbach [grosbach at apple.com] Sent:

Hi Jack, Everything should be already using the sized Emit* routines directly rather than outputting individual bytes of larger entities piecemeal. Have you found that not to be the case? The Emit* routines handle endianness for you, so you shouldn't have to do much beyond that. For example, here's the EmitInvValue() implementation that underlies things and does the endianness transform:

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 idioms makes this easier; specific instances are included in the comments: -- > diff --git

On Mon, Feb 29, 2016 at 03:47:49PM -0800, David Blaikie wrote: > On Mon, Feb 29, 2016 at 3:36 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > > Hi David, > > > > The way I imagined that we might want to extend the MCStreamer API (this > > was motivated by DIEData) is by allowing clients to move bytes and fixups > > into the MC layer. >

On Mon, Feb 29, 2016 at 3:36 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi David, > > The way I imagined that we might want to extend the MCStreamer API (this > was motivated by DIEData) is by allowing clients to move bytes and fixups > into the MC layer. > > This is the sort of API that I was imagining: > > void

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

Hi Jack, I would have expected the Mips backend to be using these routines (or more likely something on top of them) to emit the contents of the data and text sections and thus have the bit-twiddling done by these routines. I take it that's not happening? Basically, this should already work without any additional infrastructure. If it's not, something is broken and bypassing the

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

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

Hi David, The way I imagined that we might want to extend the MCStreamer API (this was motivated by DIEData) is by allowing clients to move bytes and fixups into the MC layer. This is the sort of API that I was imagining: void MoveAndEmitFragment(SmallVectorImpl<char> &&Data, SmallVectorImpl<MCFixup> &&Fixups); Note that this mirrors the