similar to: [LLVMdev] Proposal for -filetype=obj full big endian support

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

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

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

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

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

On Wed, Oct 20, 2010 at 2:56 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Gosh, this is taking a while :-) >> Is there anything else I missed? > > Another one I noticed. Instead of > >      SmallString<32> *FC = &currFileFragment.getContents(); >      (*FC) += static_cast<char>(attr); >      (*FC) += static_cast<char>(0xFF

> Hmm, I wish we had this discussion 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

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

For llvm-dwarfdump we need to handle relocations inside the debug info sections in order to successfully dump the dwarf info including strings. Nick sent out a partial patch that did this not too long ago and I've taken it and gone in a bit of a different direction, but kept the same basic architecture. In place of applying the relocations to the data we've read from disk I'm keeping

Hi all, The AsmPrinter class supports functions like EmitInt8, EmitInt16, and EmitInt32 for writing a 1/2/4 byte directive to the assembly. Each of these calls the MCStreamer::EmitIntValue method with the corresponding size. For some reason, there is no EmitInt64, and I was wondering if there was a fundamental reason why? The EmitIntValue function appears to support 8-byte inputs. I dug into

Well Jim, that may just be my problem. As background I am working on the outer reaches of llvm for the direct object output for Mips. Part of what I am to do is instruct the folks working closer to the backend what I am getting that is incorrect. My first reaction is to assume that I am being fed things the correct way and that I am not handling it correctly. I feed the compiler a source file

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

> Could you send me a patch for this ? I have tried to do similarly but cannot > get it to work. > I am working on a COFF linker for LLVM. > > Aaron http://codereview.appspot.com/1638043/show (ignore test/CMakeLists.txt) How are you planning on doing the linker? This is probably something that should be done like LLVMMC. In fact they should probably share Elf/MachO/COFF code.

On 19/12/11 08:17 PM, Carter, Jack wrote: > Proposal for ELF text and data big endian support for direct object generation Looks like the basic support is already there. If I remember correctly, what we have lets us produce a hello world on a big endian freebsd powerpc. > Cheers, > > Jack Cheers, Rafael

Well, not so flawlessly. Yes, I get hello world working, but the current place to fix up the instructions (EncodeInstruction) is too early and misses the final expression fixups. I also continue to struggle in the lib/Target/<local target>/MCTargetDesc area to get clean, easy and elegant access to the environment such as chip/instruction variants let alone endianess. Finally, I still

DWARF already needs to emit 64-bit values, being the type-unit hashes. How is that being done? (If it's going directly to the streamer, then we're already assuming all assemblers are okay with what the streamer does, and adding an AsmPrinter helper seems very reasonable.) --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of James Henderson via llvm-dev Sent:

Hello, I am trying to insert a .byte/.word in the beginning of a specific LLVM IR instruction when it prints out in assembly (the inserted ‘instruction' only appears in assembly, not in LLVM IR), and I am guessing the best way to do that is to insert it in SelectionDAG as it strips down some LLVM IR instructions when it’s lowered. Can I get some guidance on what function I should use to insert