[PATCH] [ARM] Stop the LLVM ELF streamer uppercasing NTBS data in build attributes.

[Charlie Turner]

Hi t.p.northover, jasonk,

For example,
```
$ llvm-mc -triple armv7-elf -filetype obj -o test.o
.eabi_attribute  Tag_compatibility, 136, "Foo Corp"
$ llvm-readobj -arm-attributes test.o 
...
      Attribute {
        Tag: 136
        TagName: compatibility
        Value: FOO CORP
...
```
I originally discovered this behaviour was suspect when Tim Northover commented on D6319, where he said

"What's doing the capitalisation here? It seems highly suspect (not mentioned in the ABI as far as I can tell, and gets into sticky locale questions)."

`ARMTargetELFStreamer::finishAttributeSection` unconditionally uppercases the string-valued data for build attributes, I'm not sure why.

The git logs don't shed any light on the matter for me. There was a vague reference to gas compatibility, but as of gas 2.23.2.20140731, this is not the observed behavior, the capitalization is preserved. I haven't checked older versions.

All I have managed to find is a mail discussing the behavior of an old codesourcery toolchain which uppercased .cpu values in object files, but not assembly files,

http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/87133

The following commit by Jason Kim implemented that behavior,

http://llvm.org/viewvc/llvm-project?view=revision&revision=125025

and Jason mentions this again with reference to another patch proposal that this might be expected behavior,

http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/88234/focus=88261

I'm CC'ing Jason to this issue because maybe he has some background I'm not aware of on this topic. (Not that .cpu is a build-attribute, it's just all I could find!)

I wonder if the build attribute values are being upper-cased because of the precedent set for .cpu, but that's just wild conjecture. Recent GNU tools camel case .cpu names into the object file, do we captialise for compatibility with old versions of ld perhaps?

The ARM ABI document does not mention anything about captialisation conventions, so the existing behaviour doesn't appear technically incorrect, but there are a few reasons why I think no text transformations should be applied unconditionally,

  * It's less work
  * Some vendors may legitimately have case-sensitive checks for these attributes which would fail on LLVM generated object files.
  * Locale questions? (Tim's comment).

This investigation was mostly spurred on by Tim's comments. I'm not sure myself whether this patch is the right thing for LLVM to do, I'm submitting it primarily to help frame my question.

Thank you for your time,
Charlie.

http://reviews.llvm.org/D6356

Files:
  lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
  test/CodeGen/ARM/build-attributes-encoding.s
  test/MC/ARM/directive-arch-iwmmxt.s
  test/MC/ARM/directive-arch-iwmmxt2.s
  test/MC/ARM/directive-cpu.s
  test/MC/ARM/directive-eabi_attribute-overwrite.s
  test/MC/ARM/directive-eabi_attribute.s
  test/tools/llvm-readobj/ARM/attributes.s
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D6356.16496.patch
Type: text/x-patch
Size: 5909 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141121/74ad00c3/attachment.bin>