[LLVMdev] Build Attributes Proposal

[Renato Golin]

On 13 November 2010 21:15, Duncan Sands <baldrick at free.fr> wrote:
> Since I don't know anything about these attributes, talk of indexes and
> so forth goes straight over my head.

Hi Duncan,

I assumed you knew what build attributes were in the first place, my mistake.

For a full explanation of what they are, see ARM ABI Addenda, section
2.1 (PDF). (Google's first hit for "arm abi addenda").

Simply put, build attributes express the user explicit intentions when
compiling code, so the linker can take better decisions when linking
the objects. These attributes apply normally to whole units, but could
apply to sections or even symbols, to express the compatibility or
preference towards specific components. With build attributes, it's
easier to pass information between tool chains, as some choices might
be obvious within the tool chain, but different across.

For example, the LLVM tool chain assumes that every Cortex-A8 has
NEON, while the ARM tool chain does not. So, if you compile a file
with Clang for Cortex-A8 and link with LLVM linker (or LD), everything
works fine, because that assumption is in every step of the tool
chain. However, if you try to link with armlink, it won't work, as the
NEON attribute (Tag_Advanced_SIMD_arch) will not be there, and when it
finds vector instructions, it'll bail out.

Another example I quote from the ABI:

"The compiler might choose to use only the Thumb ISA in a specific
build of a source file.
Nonetheless, the relocatable file should be tagged as having been
permitted to use the ARM ISA so that a linker can later link it with
ARM-state library code and generate ARM-state intra-call veneers if
that gives benefit to the executable file.
On the other hand, if the user intends code to be executed by both
ARM7TDMI and Cortex-M3, the compiler must be constrained to generate
only Thumb v1 instructions and the relocatable file should be tagged
as not permitted to use the ARM ISA."

So, as you can see, this gives the user and library writers freedom to
optimize and specialize their code to perfection. In a highly
segmented market such as ARM's, where every manufacturer has its own
ways to connect the components or build SoCs, this is the only way to
completely customize the tool chain to a completely customized
architecture.

Also, it's not something restricted to assembly only, but it's also
stored in ELF files (global, sections, symbols). This are also well
documented, long-lasting definitions that all ARM ABI compatible
compilers should honour when producing and consuming object files.
Specific manufacturer can also come up with a new set of attributes
that are specific to their own architecture, and as long as they don't
collide with the public definitions, other manufacturers are free to
ignore.

cheers,
--renato