similar to: [LLVMdev] subclassing MCELFStreamer

Hi Mario, On Thu, Dec 6, 2012 at 4:08 PM, Mario Guerra <mariog at codeaurora.org> wrote: > The last time the topic of subclassing MCELFStreamer came up, you both were > helpful in identifying ways to handle the use case without requiring > subclassing. Can you please take a look at the context below and let me know > if you have any suggestions? Subclassing MCELFStreamer is

> Subclassing MCELFStreamer is probably also necessary to implement mapping > symbols on ARM ELF targets (see the current thread at > http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/124737). > > Your refactoring patch on phabricator appears to be a functional subset of the one > I've posted (though obviously not textually identical). As a smaller patch, it may be

I need to sub-class MCObjectStreamer to account for some of our target-specific requirements, and it wasn't apparent to me how to register my version after reviewing and stepping through code. How do I wire up LLVM to use my sub-classed implementation instead of the default? Thanks, - -- Mario Guerra mariog at codeaurora.org Qualcomm Innovation Center Inc is a member of Code Aurora Forum,

On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote: > Jim, > > Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. > > The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer

Hi Jack, I'm not 100% up on how MIPS represents jump tables, so take with a grain of salt and all that. Normally how this stuff works is that the streamer will create Fixups (MCDataFragment::addFixup()) for anything that might require a relocation. That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for

Jim, Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer for a specific fixup. One of the issues I hit initially with llvm is that

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

On Tue, Nov 15, 2011 at 11:06 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote: > >> Jim, >> >> Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. >> >> The issue I was having was

Hi Jack, Can you elaborate a bit on what you're trying to do? Relocations are handled by the ObjectWriter interfaces, not by the streamer. The <ObjectFormat>Streamer classes aren't intended to be subclassed by targets. -Jim On Nov 14, 2011, at 5:50 PM, Carter, Jack wrote: > I need to create a subclass that derives from MCELFStreamer. > > We use MCELFStreamer for direct

I need to create a subclass that derives from MCELFStreamer. We use MCELFStreamer for direct object generation and need to override a virtual method in the base class MCStreamer::EmitGPRel32Value(). I have been having trouble creating the subclass due to #include issues. I can't seem to get it right at the lib/target/<my target>/MCTargetDesc level. My first thought is always that I am

Hello Owen, > There should already be sufficient support for what you're trying to do. See > MCOperand::CreateInst(). The concept is that you'll build a composite MCInst in > your AsmPrinter::EmitInstruction() method, which uses Inst-type MCOperands to > hold a list of sub-instructions. Then you call AsmStreamer::EmitInstruction() on the > composite MCInst. Thanks for

Mario, On Nov 29, 2012, at 4:04 PM, Mario Guerra <mariog at codeaurora.org> wrote: > Thanks for your reply. This is actually one approach we are considering, but > there are a few issues with it we weren't sure how to address. > > One is that the lifespan of an MCInst seems to be limited to the scope of > AsmPrinter, and we need them to be persistent in order to do a

I have managed to produce correct relocation records for my jump table with the below code, but am baffled to how to emit the text addresses to the data section. I'm sure it is just a few lines of code. Any suggestions? Jack void MCObjectStreamer::EmitGPRel32Value(const MCExpr *Value) { MCDataFragment *DF = getOrCreateDataFragment(); int Size = 4; // Assumption is that this is alway

Hi Jim, The diff below is not intended to be a patch, but a starting point. It is the shortest path (I hope) to getting LLVM to emit ARM mapping symbols to the ELF without changing any shared interfaces. Could you have a look at the FIXME comments and offer some pointers on how to get this code out of MCELFStreamer? Thanks, Greg diff --git a/lib/MC/MCELFStreamer.cpp b/lib/MC/MCELFStreamer.cpp

Mario, On Nov 29, 2012, at 3:00 PM, Mario Guerra <mariog at codeaurora.org> wrote: > We're developing an integrated assembler for a VLIW target, and some of the > optimizing our assembler needs to do must be done on a per-packet basis. > This requires us to be able to traverse instruction within a packet, and one > particular optimization requires traversal of previous

i want to emit binary code for the following implemented vector assembly instructions. P_256B_LOAD_DWORD R_0_R2048b_0, pword ptr [rip + b] P_256B_LOAD_DWORD R_0_R2048b_1, pword ptr [rip + c] P_256B_VADD R_0_R2048b_0, R_0_R2048b_1, R_0_R2048b_0 P_256B_STORE_DWORD pword ptr [rip + a], R_0_R2048b_0 I added the following lines in X86MCInstLower.cpp; unsigned NewOpc; switch (OutMI.getOpcode())

On Thu, Nov 29, 2012 at 3:00 PM, Mario Guerra <mariog at codeaurora.org> wrote: > Hello all, > > We're developing an integrated assembler for a VLIW target, and some of the > optimizing our assembler needs to do must be done on a per-packet basis. > This requires us to be able to traverse instruction within a packet, and one > particular optimization requires traversal

Hi folks, I'm looking for a developer to join my team in Austin to help develop linker back ends for ARM and AArch64. Given that this is the LLVM dev list, I want to be clear that the work involves close collaboration with our internal LLVM teams so LLVM experience is a definite plus, but it does not involve direct development on LLVM. I'm ideally looking for someone with direct

Hello all, We're developing an integrated assembler for a VLIW target, and some of the optimizing our assembler needs to do must be done on a per-packet basis. This requires us to be able to traverse instruction within a packet, and one particular optimization requires traversal of previous packets as well. We're considering adding support for MCInst bundles in the MC layer to

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same