search for: mcelfstream

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 in terms of relocation and fixups there was an assumption of universal fixups/relocation types. That was really Utopian. These need to be all down in...

...tch statement. This produces, in Mips, an rodata section with gp relative relocations associated with it. I know this because that is what I get when producing a .s file and then running gas on it. When compiling for direct object output I got the error stemming from MCStreamer. Since we are using MCELFStreamer, my assumption (possibly/probably wrong) was that we needed to subclass MCELFStreamer to somehow set the magic flag so that the relocation get generated. in AsmPrinter::EmitJumpTableEntry, MJTI->getEntryKind() is of type EK_GPRel32BlockAddress. Any insight is appreciated. I am rereading the...

...1, 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 for a specific fixup. > No subclassing needed. Are you sure the fixup needs to be Mips specific? That would be highly unusual for a data section. Normally, the data fixup is target-independent, then it's mapped to a...

...s otherwise via the MCObjectWriter::RecordRelocation() hook. For MachO, that's been moved to a target hook, but for ELF that's directly in ELFObjectWriter.cpp still, including all the target specific bits. For your specific problem, I suspect what needs to happen is something like: 1) In MCELFStreamer(), implement EmitGPRel32Value() to add an appropriate fixup, and 2) in ELFObjectWriter.cpp, teach the Mips bits what relocation type to use for that fixup, if it doesn't know already. (MipsELFObjectWriter::GetRelocType()). Regards, -Jim On Nov 15, 2011, at 9:57 AM, Carter, Jack wrote: &gt...

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

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

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

..., 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 for a specific fixup. >> > > No subclassing needed. Are you sure the fixup needs to be Mips specific? That would be highly unusual for a data section. Normally, the data fixup is target-independent, then it's...

...m, 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 index 8107005..153ca78 100644 --- a/lib/MC/MCELFStreamer.cpp +++ b/lib/MC/MCELFStreamer.cpp @@ -40,12 +40,14 @@ class MCELFStreamer : public MCObjectStreamer { public: MCELFStreamer(MCContext &Context, MCAsmB...

...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 "correct" way to write out these blobs in ELF is to add a new virtual interface to MCElfStreamer to emit the ARM specific chunks. I'd prefer to add a new subclass of MCELFStreamer to do this, but, it looks like the registration mechanism for streamer does not encourage this. The other possibility is to add in special case code to MCELFStreamer directly, which seems messy too. I am guessi...

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

...k your test passes when what actually happened is that both objects were compiled with GCC! Thanks, Greg On Tue, Oct 16, 2012 at 1:03 PM, Renato Golin <rengolin at systemcall.org> wrote: > On 16 October 2012 03:16, Greg Fitzgerald <garious at gmail.com> wrote: >> Lastly, from MCELFStreamer, how do I determine if we generating an ARM or >> Thumb ELF? > > That was the only part I didn't know how to get. Jim should know. > > >> I can catch Thumb from the EmitThumbFunc, but that seems a >> little odd. > > Ignore EmitThumbFunc, it has nothing to d...

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 probably also necessary to implement mapping symbols o...

> 1. What is the preferred method in MC to jump back to a prior section > already defined? (Or is this not supported?) SetSection in the MCStreamer if you really want to change the current section, but maybe all that you need is to setSection in the Symbol? Similar to what is done in MCELFStreamer::EmitCommonSymbol if the binding is local. > 2. It looks like the "correct" way to write out these blobs in ELF  is > to add a new virtual interface to MCElfStreamer to emit the ARM > specific chunks. > I'd prefer to add a new subclass of MCELFStreamer to do this, but,...

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

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

...etection previously used only for ASM output, to object output, via the EmitDataRegion/EmitDataRegionEnd. I haven't looked too deep in the MC, but I'm supposing that will work automatically when the output streamer is printing object code and meets a non-code region, so in theory, changing MCELFStreamer accordingly (overriding those functions in there) would take care of data vs. code issue in ELF. Assuming LLVM doesn't generate ARM/Thumb veneers inside the same function (ie. a Thumb function has only Thumb code), Greg could use the EmitDataRegion and EmitDataRegionEnd, with the former savi...

...RM backend where data-in-code regions get created (jump tables, constant pools, et. al.). > I haven't looked too deep in the MC, but I'm supposing that will work > automatically when the output streamer is printing object code and > meets a non-code region, so in theory, changing MCELFStreamer > accordingly (overriding those functions in there) would take care of > data vs. code issue in ELF. Yep. They'll likely be implemented as, effectively, an EmitLabel(). > Assuming LLVM doesn't generate ARM/Thumb veneers inside the same > function (ie. a Thumb function has on...

...sData); I'd use an enum, or have multiple internal implementations... EmitDataMappingSymbol -> { nop on base class, on ARM, prints "$d" } EmitCodeMappingSymbol -> { nop on base class, calling either EmitThumbMappingSymbol or EmitARMMappingSymbol (private) on ARM } > +void MCELFStreamer::EmitMappingSymbol(bool IsData) { > + // FIXME: The following is specific to the ARM. This should be moved > + // to ARMAsmBackend. Maybe MCARMELFStreamer (or whatever sounds nicer than that). ARMAsm is a big bag of code and nowadays, most of it is format agnostic, I think (asm,...

On Oct 5, 2012, at 12:15 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Greg, > >> Is this a bug? If so, how can I fix it? > > It's somewhere between a bug and a quality-of-implementation issue. > ARM often uses literal pools in the middle of code when it needs to > materialize a large constant (or variable address more likely for >