search for: emitthumbfunc

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 do with your change. > $ readelf -s via-llvm-as.o | grep "\$." > 2: 00000000 0 NOTYPE LOCAL DEFAULT 4 $d > 3: 00000000 0 NOTYPE LOCAL DEFAULT 4 $t Clearly, you're not de...

...humb code), Greg could use the EmitDataRegion and EmitDataRegionEnd, with the former saving the state of the current code (Thumb/Arm) and the latter restoring it, by emiting the $d and $a/t respectively. Does it seem like a good initial approach? Continuing... It seems MCELFStreamer already has a EmitThumbFunc, which looks to me as the wrong place to be. I'd imagine MCELFStreamer would have EmitFunc and MCARMELCStreamer (or whatever) would identify its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being pedantic, even that is still too high level because of the ARM/Thumb veneers, but we do...

...EmitDataRegion and EmitDataRegionEnd, with the former saving the > state of the current code (Thumb/Arm) and the latter restoring it, by > emiting the $d and $a/t respectively. > > Does it seem like a good initial approach? > > Continuing... It seems MCELFStreamer already has a EmitThumbFunc, > which looks to me as the wrong place to be. That's just the handler for the .thumb_func directive. It has nothing to do with emitting the contents of the actual function. > I'd imagine MCELFStreamer > would have EmitFunc and MCARMELCStreamer (or whatever) would identify > i...

...s, as defined in 4.6.5.1 of the ELF for ARM document? And what to put in the alignment field? I see GCC outputting 1, 3, 4, but I don't see a description of that field in the doc. Lastly, from MCELFStreamer, how do I determine if we generating an ARM or Thumb ELF? I can catch Thumb from the EmitThumbFunc, but that seems a little odd. Suggestions? Here's what I have so far: $ readelf -s via-llvm-as.o | grep "\$." 2: 00000000 0 NOTYPE LOCAL DEFAULT 4 $d 3: 00000000 0 NOTYPE LOCAL DEFAULT 4 $t $ readelf -s via-gcc-as.o | grep "\$." 5: 000000...

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 >

...itDataRegionEnd, with the former saving the >> state of the current code (Thumb/Arm) and the latter restoring it, by >> emiting the $d and $a/t respectively. >> >> Does it seem like a good initial approach? >> >> Continuing... It seems MCELFStreamer already has a EmitThumbFunc, >> which looks to me as the wrong place to be. > > That's just the handler for the .thumb_func directive. It has nothing to do with emitting the contents of the actual function. > >> I'd imagine MCELFStreamer >> would have EmitFunc and MCARMELCStreamer (or whatev...

...ctober 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 do with your change. > > >> $ readelf -s via-llvm-as.o | grep "\$." >> 2: 00000000 0 NOTYPE LOCAL DEFAULT 4 $d >> 3: 00000000 0 NOTYPE LOCAL DEFAULT...

...former saving the >>> state of the current code (Thumb/Arm) and the latter restoring it, by >>> emiting the $d and $a/t respectively. >>> >>> Does it seem like a good initial approach? >>> >>> Continuing... It seems MCELFStreamer already has a EmitThumbFunc, >>> which looks to me as the wrong place to be. >> >> That's just the handler for the .thumb_func directive. It has nothing to do with emitting the contents of the actual function. >> >>> I'd imagine MCELFStreamer >>> would have EmitFunc and M...

...er, Assembler) {} + : MCObjectStreamer(Context, TAB, OS, Emitter, Assembler), + IsThumb(false), MappingSymbolCounter(0) {} ~MCELFStreamer() {} @@ -58,6 +60,7 @@ public: virtual void EmitLabel(MCSymbol *Symbol); virtual void EmitAssemblerFlag(MCAssemblerFlag Flag); virtual void EmitThumbFunc(MCSymbol *Func); + virtual void EmitDataRegion(MCDataRegionType Kind); virtual void EmitAssignment(MCSymbol *Symbol, const MCExpr *Value); virtual void EmitWeakReference(MCSymbol *Alias, const MCSymbol *Symbol); virtual void EmitSymbolAttribute(MCSymbol *Symbol, MCSymbolAttr Attribute); @...

Great, thanks for your help. I'll take a crack at it and contact Renato if I have questions. -Greg On Wed, Oct 10, 2012 at 1:05 PM, Jim Grosbach <grosbach at apple.com> wrote: > Cool; glad to help. > > When I added the data region bits, I tried to keep the ARM-style annotations in mind a bit, so hopefully things will fit together without too much trouble. > > -Jim >