On 3 August 2012 12:00, Richard Earnshaw rearnsha@arm.com wrote:
On 02/08/12 18:39, Mans Rullgard wrote:
Nevertheless, the tags in the .ARM.attributes section are the standard, published way to identify FP ABI as well as a number of other properties that might be relevant to a linker.
- The attributes only visible in the section view (as used by linkable
object files). You can't rely on that being present in an executable image.
If not present, assuming it is compatible should be good enough.
- The encoding has been arranged for density, not performance; it's
unsuitable for low-cost look-ups when searching a chain of libraries.
Attributes were never intended for use at run time; IMO it would be a mistake to try and coerce them into such a role.
Well, clearly nobody thought that information would be used _at all_ at runtime. Now people apparently want that, so something has to change.
Duplicating the attribute information in the 8-bit OSABI field is not going to work since there are more than 8 attributes.
If directly examining the attributes section is out of the question, perhaps the e_flags field would be a better option than OSABI, being clearly designated as a collection of flags and also having more bits currently unused.
Keep in mind that changing the ELF header will require an update to the ARM ELF specification, and is likely to cause compatibility problems with other toolchain vendors until they make the corresponding changes. Using existing sections does not have this problem.