[LLVMdev] Does LLVM sign ARM ELFs?

[Greg Fitzgerald]

> I wouldn't rely on that.
>
> I'm not sure what's your objective

Agreed, thanks Renato.  My objectives:

1) Add a patch to enable the integrated assembler by default when
targeting ARM or Thumb with ELF.  The patch is very tiny - you
override a virtual method for the toolchain.  But you do it in a base
class so a little fragile.  It deserves a test.
2) Demonstrate a "gotcha" in Clang where you tell it to use the
integrated assembler, but it doesn't.

I'm interested what else might prevent us from enabling the
integrated-assembler by default.  It's already enabled for MachO, so
I'm not too concerned about the quality of the code generated.  To
double-check, I've disassembled over 5,000 unique object files and
compared to GCC disassembly, and things are looking very good.  My
Mapping Symbols patch was key to ensuring minimal noise in that
analysis.  At this point, my biggest concern is the quality of the
ElfStreamer, and I haven't done anything to verify the linker.  But
everything seems to "just work", so maybe time to go find bigger fish
to fry?  What do you think?  Should we flip the switch?

Thanks,
Greg


On Tue, Nov 20, 2012 at 1:06 AM, Renato Golin <rengolin at systemcall.org> wrote:
> On 20 November 2012 03:22, Greg Fitzgerald <garious at gmail.com> wrote:
>> I read through "ELF for the ARM Architecture" and my best guess has
>> been to inspect .ARM.attributes in the elf-dump's section data, but
>> both LLVM and GCC use "aeabi" for the vendor name.
>
> "aeabi" is the "pseudo-vendor" which is normally printed to the
> attributes section. There could be more vendor tags, and LLVM could
> easily do that.
>
> From the ABI:
>
> We expect a dot-ARM-dot-attributes section in a relocatable file will
> most typically contain one vendor subsection
> from the "aeabi" pseudo-vendor and possibly one from the generating
> tool chain (e.g. "ARM", "gnu", "WRS", etc).
>
> Amara,
>
> Maybe another thing to add to your attributes patch, adding some
> vendor specific info to it (like clang/version, llvm/version,
> integrated-as, etc)?
>
>
>> I've found several ways to distinguish the two (such as a magic number
>> where GCC uses ELFOSABI_SYSV and LLVM uses ELFOSABI_LINUX), but hoping
>> for something more reliable, like a toolchain signature.
>
> I wouldn't rely on that.
>
> I'm not sure what's your objective, but in the past when I had to test
> separate binaries generated from integrated-as and compare to GAS
> generated objects I just had different names for the objects in the
> Makefile. If you don't control the source, however, might prove a
> little more difficult.
>
> --
> cheers,
> --renato
>
> http://systemcall.org/