[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