[llvm-commits] [PATCH] ARM/MC/ELF e_flags fixup - add an ARMMCCodeEmitterBase class?

[Jason Kim]

On Fri, Feb 4, 2011 at 12:21 PM, Jim Grosbach <grosbach at apple.com> wrote:
> 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.

Thanks for the advice, Jim!
I'll put it in ARMELFObjectWriter as you suggest.

-jason

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