On Tue, Jun 19, 2007 at 01:50:27AM +, 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.
