similar to: [LLVMdev] Emitting switch table data to section (previously - subclassing MCELFStreamer)

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

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

So what I am hearing is that I should add the following to MC/MCFixup.h: FK_GPRel_1, ///< A one-byte pc relative fixup. FK_GPRel_2, ///< A two-byte pc relative fixup. FK_GPRel_4, ///< A four-byte pc relative fixup. FK_GPRel_8, ///< A eight-byte pc relative fixup. In MC/MCStreamer.cpp MCStreamer::EmitGpRel32Value() Figure out how to mark it with the imprint of

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

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

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

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

Hi Jim, Daniel, 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? For reference, this was posted to the list yesterday under the subject "sub-classing MCObjectStreamer?": > Okay,

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

> 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

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

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

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

OK, after reading the docs I have some extra comments (and an updated patch). *) To support per section or per symbol attributes we would have to move this to the processing done in the end of the file. Lets not do this right now. *) We don't currently use any string attributes, so I did not implement them. *) Having an attribute emitter class is a nice way to separate the job of creating the

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

I was mistaken as to needing the virtual address of the section , but really need to know the virtual address of the beginning of the function that contains the label whose symbol expression we have. I have a case where I the expression (MCSymbolRefExpr) is the offset from the beginning of the function. AsmPrinter::EmitJumpTableEntry() calls