search for: mcarmelcstreamer

...ent 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 don't want to worry about that if LLVM doesn't even try to mix ARM and Thumb (and assuming external libraries...

.... 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 > 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 don't want to worry about that if LLVM doesn't even > try to mix ARM and Thumb (and assuming...

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 >

...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 >> 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 don't want to worry about that if LLVM doesn't even >> try to mix ARM and Thu...

...c, >>> 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 >>> 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 don't want to worry about that if LLVM doesn't even >>> try to...