Object attribute tagging

[Joseph S. Myers]

The question was raised a while back on the gcc-patches and gdb-patches 
lists of how GCC should tag objects with some ABI information for the use 
of GDB, noting that various different methods have been in use 
<http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00395.html>.

Mark suggested <http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00854.html> 
that we use the ARM EABI object attribute mechanism; there were no 
objections to this at that time.  This provides for both 
processor-specific and vendor-specific tags, and for tags at the level of 
object files, sections or individual functions (although binutils only 
really supports tags at the object file level at present).  Tags can be 
merged from input files (with compatibility and merging rules defined) to 
produce the tag in an output file; the linker can give a warning or error 
for incompatible tags (e.g. object files using different ABI variants).

I now propose implementing this to mark MIPS and Power objects with 
whether they are using the hard-float or soft-float ABI, both so the 
linker can complain if users accidentally link incompatible objects 
together, and so GDB knows the ABI in use by a binary.  (It's desirable to 
know the ABI even in the absence of debug information, e.g. to call 
functions in libc, so DW_AT_calling_convention doesn't seem a sufficient 
alternative.)

The ARM EABI uses a .ARM.attributes section of type SHT_ARM_ATTRIBUTES.  
For platforms where there isn't such a specification for that processor, I 
propose .GNU.attributes and SHT_GNU_ATTRIBUTES, and an assembler directive 
.gnu_attribute in place of .eabi_attribute.  This would generate entries 
under the "gnu" vendor (whereas .eabi_attribute uses the standard 
"aeabi"); if more processor ABI specifications pick up the attributes 
specification then we could switch to appropriate processor-specific 
sections.  On ARM, both .gnu_attribute and .eabi_attribute could be used, 
and would both generate entries in .ARM.attributes, under the "gnu" and 
"aeabi" vendors respectively.  Appropriate parts of the ARM binutils code 
would be made available to all ELF binutils targets.

The ARM EABI says that only standard entries under "aeabi" should affect 
link-compatibility of object files, not vendor entries such as "gnu", but 
in the absence of corresponding standards for other processors I don't 
think we can avoid use of "gnu" for link-compatibility on non-ARM 
processors for now - if processor ABIs standardize things in future we can 
deprecate the associated "gnu" attributes.

Additional object tagging ay be of use in future with LTO, to mark objects 
with information about command-line options used where such options are 
relevant to code generation but not recorded directly in the IR (e.g., 
target-specific options selecting CPU features that may be used or 
built-in functions that are enabled).  We can allocate such tags in future 
as and when needed.  I propose to establish some convention for which 
"gnu" attributes are target-dependent and which are target-independent.

Any comments on either the general approach or the details?

-- 
Joseph S. Myers
joseph@codesourcery.com