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

[H.J. Lu]

On Tue, Aug 19, 2025 at 6:50 PM Cary Coutant <ccoutant@gmail.com> wrote:
>
> > 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).
>

The section in question is .rodata.  Some tools don't work with non-zero
sh_entsize on .rodata.   How should a tool interpret non-zero sh_entsize
on these special sections?

-- 
H.J.