This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Object attribute tagging
- From: "H. J. Lu" <hjl at lucon dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, binutils at sourceware dot org
- Date: Mon, 18 Jun 2007 19:41:21 -0700
- Subject: Re: Object attribute tagging
- References: <Pine.LNX.4.64.0706190127310.4094@digraph.polyomino.org.uk>
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.