This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Object attribute tagging
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: gcc at gcc dot gnu dot org, binutils at sourceware dot org
- Date: Tue, 19 Jun 2007 01:50:27 +0000 (UTC)
- Subject: Object attribute tagging
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
joseph@codesourcery.com