On Tue, Jun 19, 2007 at 01:50:27AM +0000, Joseph S. Myers wrote: > 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? >
I like this initiative. For x86, currently we have no way to make an object/shared library to indicate 1. Different parameter passing schemes: on stack vs. in registers. It could be even per function based. 2. Different alignment requirements. -malign-double. 3. Different long double. -m128bit-long-double vs. -m96bit-long-double. 4. Different ISAs, x87, SSE, SSE2, .... 5. Different fpmath. x87 vs. SSE. 6. Different x86-64 models. 7. With or without x86-64 red zone. 8. Different x86-64 ABIs. ELF vs. Win64. 9. Different ia32 stack aligment requirements. psABI only requires 10. byte alignment and gcc wants 16. It will be nice to address those issuses in a general and extensible way. H.J.
