similar to: [LLVMdev] MCELFStreamer subclassing

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

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

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

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

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

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

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

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,

> 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

Hi, I've run Clang Static Analyzer checker alpha.cplusplus.NewDeleteLeaks over LLVM codebase to detect false-positives and at the same time eliminate memory leaks. The majority of leaks were detected in lib/Target/* and lib/MC/*. In all cases the similar trick was detected as a leak (example from lib/Target/Sparc/MCTargetDesc/SparcMCTargetDesc.cpp) : static MCStreamer

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 everyone, while looking at the ARMAsmPrinter::EmitStartofAsm function, I realized that what looks like singular assembler directives (.eabi_attribute) are in fact shorthand that needs to go in to the .ARM.attributes section in the ELF file. 1. What is the preferred method in MC to jump back to a prior section already defined? (Or is this not supported?) 2. It looks like the

On Oct 7, 2012, at 3:14 AM, Renato Golin <rengolin at systemcall.org> wrote: > On 5 October 2012 17:48, Jim Grosbach <grosbach at apple.com> wrote: >> The recent MachO data-in-code support should have fixed a lot of the problems. There's probably still some quirks in the specifics ($a vs. $t and making sure the symbols get into the ELF properly), but the core

On 5 October 2012 17:48, Jim Grosbach <grosbach at apple.com> wrote: > The recent MachO data-in-code support should have fixed a lot of the problems. There's probably still some quirks in the specifics ($a vs. $t and making sure the symbols get into the ELF properly), but the core functionality to know how to mark data regions is there and works very well. Hi Jim, I'm trying to

Thanks Jim! I have updated the bug with your comments, I think it's a good start. Greg, let me know if that's not enough, I think I can help you from now on. cheers, --renato On 9 October 2012 23:58, Jim Grosbach <grosbach at apple.com> wrote: > > On Oct 7, 2012, at 3:14 AM, Renato Golin <rengolin at systemcall.org> wrote: > >> On 5 October 2012 17:48, Jim

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

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

On 12/15/2012 12:53 PM, Chandler Carruth wrote: > On Sat, Dec 15, 2012 at 12:33 PM, Reed Kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > > I have an approved target independent putback and i've run all > that we have at Mips as well as on x86 " make TEST=simple" > > Is there anything else that is easy to run that I

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: