Re: RFC [PATCH] Use .strtab section for section name strings

[Cary Coutant <ccoutant at gmail dot com>]

>> Here is a patch to use .strtab section for section name strings if
>> there are symbols, otherwise use .shstrtab section.
>
> I think this is a bad idea.
> ...
> The great majority of object files won't see as much benefit.  I
> reckon shared libraries and executables will only show very small
> decreases, at the cost of violating the ELF gABI.

To be fair, I don't think this would violate the spirit of the ELF
spec. The spec doesn't clearly require that the section strings and
symbol strings be in separate tables, and a proper ELF consumer will
use the e_shstrndx field to find the section string table, and will
use the sh_link field of the symbol table section header entry to find
the symbol string table. It does list .strtab and .shstrtab as
"special sections", but one could argue that that's advisory, since a
consumer should never need to use the section name to understand what
a section is for (at least as far as the gABI goes). I haven't tried
it, but I suspect gold would handle such a file without complaint, and
I'd treat it as a bug if it didn't.

Nevertheless, I don't think this is the right solution to the problem,
which is that symbol names have crept into the section names in the
form of COMDAT and -ffunction-sections. When I first implemented
COMDAT sections in HP-UX, I made the section name the comdat key,
which effectively required the compiler to put mangled C++ names in
the section string table, most of which already had to be in the
symbol string table anyway. In the process of standardizing them in
the gABI, we corrected that by defining the comdat key as a symbol, so
that we didn't have to emit any mangled names into the section string
table.

GCC's implementation, however, still appends a mangled name to the
section name, quite unnecessarily, and also does so for
-ffunction-sections. Rafael Espindola has proposed a new .section
directive syntax that would allow the compiler to generate multiple
.text sections without having to decorate the section name with a
unique symbol name, and I think *that's* the right way to reduce the
size of the section string table.

We still have some dependencies on fully-decorated section names,
though. Some apps have linker scripts that depend on picking out
specific sections by name, so we'd probable have to continue to
support the full decoration for those apps. Gold has a
--section-ordering-file option that lets you specify a section
ordering, and there are external tools that build a section ordering
file from profile output; ultimately, I'd prefer to rework that option
to allow ordering by symbol name instead of section name.

-cary