Re: Object attribute tagging

["H. J. Lu" <hjl at lucon dot org>]

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.