[PATCH] ld: entry size and merge/strings attributes propagation

[Cary Coutant]

> gABI has
>
> sh_entsize
> Some sections hold a table of fixed-size entries, such as a symbol
> table. For such a section, this member gives the size in bytes of each
> entry. The member contains 0 if the section does not hold a table of
> fixed-size entries.
> ...
> If sh_entsize != 0 and SHF_MERGE or SHF_STRINGS bits are't set, ELF tools
> may not work properly.   I think
> ...
> should be reverted.  If we want to allow non-0 entity size for
> arbitrary sections,
> it should be discussed at gABI group first:

If you're thinking that the ELF spec doesn't allow non-zero sh_entsize
for anything other than merge sections, I think you've misread the
spec. In fact, the text you quoted from the spec gives a specific
example of a non-merge section that uses sh_entsize: "such as a symbol
table."

The sh_entsize field has been part of ELF from the beginning, and was
meant to provide the entry size for any section that might have
fixed-size entries, whether special sections — like symbol tables,
relocations, dynamic sections — or ordinary PROGBITS sections. Since
the section header table and program header table are not themselves
sections, they have entsize fields in the ELF header. The original
purpose for the field was to allow for extensibility — theoretically,
one could extend a structure with extra fields, and the entsize field
would in effect "version" that structure. In practice, we have never
extended an ELF structure this way.

Merge sections were added much later (ca. 1999), and the use of the
sh_entsize field to describe the fixed-size entries or (for strings)
the fixed-size character width was natural. In effect, a constant
merge section is a table of fixed-size entries. A string merge section
is more of a stretch — it's really a table of variable-sized strings,
but at a lower level, it is also kind of a table of fixed-size
characters.

For other sections, sh_entsize can certainly be used for any
structured program data, such as unwind tables or other metadata.

If any tools can't handle a non-zero sh_entsize field for non-merge
sections, they should be fixed. Unless they care about the structure
and contents of the data in those sections, they shouldn't even care
about the value of sh_entsize. If they do care about the structure and
contents, they could use that field as a versioning mechanism (or at
least a sanity check that the producer isn't out of sync with the
consumer).

-cary