llvm dev - Nov 2012 - [LLVMdev] Does LLVM sign ARM ELFs?

Is there a reliable way to unit-test that LLVM's integrated assembler was
used?

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.

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.  Is there
anything like that?

Thanks,
Greg

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/

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

> From the ABI:
> Maybe another thing to add to your attributes patch, adding some
> vendor specific info to it (like clang/version, llvm/version,
> integrated-as, etc)?
This is a possibility, though I suspect that you can just use elf-dump if
you know what you're looking for. As you know the patch is specialized to
the public aeabi vendor but LLVM is free to define its own byte format
according to the spec.

Amara