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
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.
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
Hi Greg,
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?
I'd be in favour of it. All of the gaps I'm aware of (haphazard build
attributes mainly) are equally applicable to both integrated and GAS
assembly. It's possible we mis-tag a section or a symbol somehow, but
hopefully nothing substantial.
Tim.
Is there any test using the integrates assembler on ARM? Does the
nightly test-suite passes on ARM (as much as it passes with GAS)?
If so, I think we now it's the best time to turn it on, since it'll be
a while until 3.3 and we'll have plenty of time to catch the silly
bugs before a proper release.
I'd be in favour of it. All of the gaps I'm aware of (haphazard build
attributes mainly) are equally applicable to both integrated and GAS
assembly. It's possible we mis-tag a section or a symbol somehow, but
hopefully nothing substantial.
Is there any test using the integrates assembler on ARM? Does the
nightly test-suite passes on ARM (as much as it passes with GAS)?
Do you mean a test-suite run that passes integrated-as? There's the
usual clutch of regression tests that pass, but I don't know if any
build-bots run anything using it.
Unfortunately I suspect the things that are most likely to fall over
are weird bare-metal systems people have that rely on esoteric ELF
properties in some way. I suspect I could break ELF output in a dozen
ways without affecting what actually happens on arm-none-linux-gnueabi
with a standard linker.
If so, I think we now it's the best time to turn it on, since it'll be
a while until 3.3 and we'll have plenty of time to catch the silly
bugs before a proper release.
Certainly agreed there. It's best to have a good run-up where people
can file bugs.
Tim.
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
Hi Tim, Renato,
Revisiting this one from about a month back, is anyone tracking what GAS assembly compatibility issues remain? If we only need to compile C and C++, things are looking very good, but when you throw handwritten assembly into the mix, not so much. The goal is GAS compatibility, right? Not UAL? Or is there a hope to make both work?
Thanks,
Greg
Hi Greg,
The goal is GAS compatibility, right? Not UAL? Or is there a hope to
make both work?
I think UAL is mostly concerned about the mnemonics and actual
instructions accepted -- and GAS tries to stick to it, so there
shouldn't be many barriers to both working.
Off the top of my head, I know that the alignment specifiers for
certain instructions are different in GAS and UAL (though I believe
we're actually in the process of making GAS syntax blessed, if not
canonical, anyway); and possibly '#' for immediates, though I couldn't
find any actual documents requiring it in a quick search.
Tim