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 [EMAIL PROTECTED]
