[llvm-commits] [PATCH] ARM/MC/ELF e_flags fixup - add an ARMMCCodeEmitterBase class?
Jim Grosbach
grosbach at apple.com
Fri Feb 4 12:21:14 PST 2011
The MCCodeEmitter shouldn't have any coupling to TargetMachine (including the ARMSubtarget) either. That it currently does is a bug, not a feature.
This seems like it properly belongs in the ARMELFObjectWriter bits, perhaps with some ABI detection (from the Triple, most likely) logic added later if necessary.
-Jim
On Feb 4, 2011, at 12:15 PM, Jason Kim wrote:
> Hi everyone,
>
> With some chagrin, I discovered that the existing ARM/GNU tool chain
> requires a non-zero ELF e_flags field.
> Specifically, a nonzero value between 4 and 5 for the EF_ARM_EABIMASK
>
> Without this field, none of the ELF .o files link properly!
>
> Adding it in is easy enough to do, but the right place to do this
> seems to be within ARMSubtarget, which is problematic.
> So the workaround is to add a small ARMMCCodeEmitterBase class to hold
> the e_flags value to be emitted.
>
> I can just as easily just hack this in within ARMELFObjectWriter, but
> this seems to be messier, as I can forsee different values being
> emitted depending on which ABI version LLVM should emit code for -
> which seems to belong in ARMSubtarget (which is hidden from the MC
> backend ...)
>
> In any case, some form of this flag value needs to be emitted.
> Otherwise none of the ELF .o files will be linkable with existing
> tools (!)
>
> Is it OK to add in this class? Is there a better place to put this
> flag? Should I just hardcode in 5 (which is current, but existing
> tools seem to like 4 too.)?
>
> Thanks!
>
> -jason
> <arm-mc-elf-s36-attrs.patch>
More information about the llvm-commits
mailing list