[PATCH] Section Anchors and named sections

David Edelsohn dje@watson.ibm.com
Sat Apr 22 17:39:00 GMT 2006


	The specific problem that I encountered on AIX was during the
libstdc++ compilation of libstdc++-v3/libsupc++/tinfo2.cc and
libstdc++-v3/src/locale.cc in 64-bit mode.  libstdc++ is compiled with
-fdata-sections.  These files produce objects like "typeinfo name for
char" and "typeinfo name for std::locale::facet".  These typeinfo DECLs
are an array of chars.

	PowerPC defines DATA_ALIGNMENT to increase the alignment of arrays
of chars to BITS_PER_WORD alignment (64 bits in 64 bit mode) to speed up
copying (similar to CONSTANT_ALIGNMENT increasing the alignment of
constant strings).  Also keep in mind that section_type_flags for AIX
always sets the minimum alignment of sections to 32 bit alignment.

	Without section anchors, assemble_variable() calculates the
increased alignment and then get_variable_section() proceeds to call
resolve_unique_section() to set the unique section requested by
flag_data_sections.  get_named_section() calls the target hook to
calculate the flags, which encodes the section alignment on AIX, and the
section is generated by get_section().

	With section anchors, get_block_for_decl() calls
get_variable_section() without invoking DATA_ALIGNMENT.  This proceeds
down the same path as above and flag_data_sections causes
resolve_unique_section() to set the unique section name.  The DECL now has
a unique section.  get_named_section() calculates the flags, but the DECL
still has QImode 8 bit alignment.  The flags calculation sets the section
alignment to the minimum of 32 bit and get_section() stores the section
info in the hash table.

	Later when assemble_variable() comes along, DATA_ALIGNMENT is
applied, the unique section name already exists, get_named_section()
requests the section from get_section(), and get_section() finds it in the
hash table.  The DECL now has 64 bit alignment and requests a matching
section alignment; the section stored in the hash table has 32 bit
alignment.  get_section() performs a sanity check on the flags and reports
the non-fatal error:

error: <decl> causes a section type conflict

This particular example may be specific to AIX, but I can imagine another
target changing small data section choice based on an alignment or padding
change.

	AFAICT, GCC does not have any way to distinguish between a unique
section and a named section.  A unique section simply chooses a unique
name and then sets the section name.

	I agree that having anchors in named sections makes sense.  The
problem is that there are more ways to create DECLs with unique sections
than DECL_ONE_ONLY.  Specifically, resolve_unique_section() logic is:

  if (DECL_SECTION_NAME (decl) == NULL_TREE
      && targetm.have_named_sections
      && (flag_function_or_data_sections
          || DECL_ONE_ONLY (decl)))
    targetm.asm_out.unique_section (decl, reloc);

so either flag_data_sections or DECL_ONE_ONLY.  The section anchor logic
specifically excludes DECL_ONE_ONLY DECLs:

      /* There's no point using object blocks for something that is
         isolated by definition.  */
      if (DECL_ONE_ONLY (decl))
        return NULL;

but DECLs placed in unique sections are not skipped.

	With the change to apply DATA_ALIGNMENT to section anchor block
DECLs, the files will compile correctly, but GCC can produce anchors in
unique sections.  That will work and does not produce an extra indirection
on AIX, but it is clumsy and wasteful.  I would be happy with at least the
alignment change part of the patch.

Thanks, David



More information about the Gcc-patches mailing list