ld(1) string table merging could be much faster
The string table merging in ld is currently quadratic in the number of sections and relocations in the input objects. This is usually not noticeable, but objects produced with -fdata-sections (or equivalent) can quickly cause this to be meaningfully problematic.
We should store affected relocations and symbols per output section to speed this up considerably.
Similarly, if a given output section has only one mergable input section, we can skip processing entirely and trust in whatever produced the object to have merged already.
Updated by Rich Lowe about 1 month ago
illumos builds and checking the results, checking that strings remain in data sections (though not necessarily in the same places). Soaking on my own systems, which includes building various 3rd party things and having them work. Coincidentally to another bug fix, also build/compare of the llvm/clang test suites with no new additional failures.
Updated by Electric Monk 26 days ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
commit 252adeb303174e992b64771bf9639e63a4d55418 Author: Richard Lowe <firstname.lastname@example.org> 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 <email@example.com> Reviewed by: Robert Mustacchi <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>