ld(1) string table merging should follow gABI more closely
When we merge string tables, at present we only include strings referenced by symbols or relocations. Dropping any others.
This is perhaps a reasonable (but questionable, per the ABI) mode of compressing loadable sections. However for others, such as .comment this causes us to replace their mergable content with the null string.
The data in the section may be merged to eliminate duplication. Unless the SHF_STRINGS flag is also set, the data elements in the section are of a uniform size. The size of each element is specified in the section header's sh_entsize field. If the SHF_STRINGS flag is also set, the data elements consist of null-terminated character strings. The size of each character is specified in the section header's sh_entsize field.
Each element in the section is compared against other elements in sections with the same name, type and flags. Elements that would have identical values at program run-time may be merged. Relocations referencing elements of such sections must be resolved to the merged locations of the referenced values. Note that any relocatable values, including values that would result in run-time relocations, must be analyzed to determine whether the run-time values would actually be identical. An ABI-conforming object file may not depend on specific elements being merged, and an ABI-conforming link editor may choose not to merge specific elements.
Making it clear that each element in the section must be merged, not merely referenced ones. Unless we take a particularly sharp view of "identical values at program run time" to mean that things with no meaningful value at runtime can be thrown away.
Updated by Electric Monk 21 days ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
commit 252adeb303174e992b64771bf9639e63a4d55418 Author: Richard Lowe <email@example.com> Date: 2021-11-06T19:54:00.000Z 14155 ld(1) string table merging could be much faster 14157 ld(1) string table merging should follow gABI more closely Reviewed by: Toomas Soome <firstname.lastname@example.org> Reviewed by: Robert Mustacchi <email@example.com> Approved by: Dan McDonald <firstname.lastname@example.org>