This is an archive of the discontinued LLVM Phabricator instance.

[ELF2] Determine the order of entries of symbol tables in the finalize() phase.
ClosedPublic

Authored by ikudrin on Oct 20 2015, 12:42 PM.

Details

Summary
  • Move the responsibility to call SymbolBody::setDynamicSymbolTableIndex() from hash table to dynamic symbol table.
  • Hash table is not longer responsible for filling dynamic symbol table.
  • The final order of symbols of both symbol tables is set before writing phase starts.

Diff Detail

Repository
rL LLVM

Event Timeline

ikudrin updated this revision to Diff 37911.Oct 20 2015, 12:42 PM
ikudrin retitled this revision from to [ELF2] Determine the order of entries of symbol tables in the finalize() phase..
ikudrin updated this object.
ikudrin added reviewers: rafael, ruiu.
ikudrin added a project: lld.
ikudrin added a subscriber: llvm-commits.
ruiu added inline comments.Oct 20 2015, 12:58 PM
ELF/OutputSections.cpp
694–697 ↗(On Diff #37911)

Do we have to sort them even if isDynamic() is false?

698 ↗(On Diff #37911)

Early return.

if (!StrTabSec.isDynamic())
  return;
ELF/Writer.cpp
512–514 ↗(On Diff #37911)

Remove {}.

ikudrin added inline comments.Oct 20 2015, 2:03 PM
ELF/OutputSections.cpp
694–697 ↗(On Diff #37911)

It's a replacement for removed lines 813-818.

ruiu added inline comments.Oct 20 2015, 2:08 PM
ELF/OutputSections.cpp
699–702 ↗(On Diff #37911)
size_t I = 0;
for (SymbolBody *B : Symbols)
  B->setDynamicSymbolTableIndex(++I);
829–832 ↗(On Diff #37911)

You can inline this function in .h.

ikudrin updated this revision to Diff 37916.Oct 20 2015, 2:14 PM
  • Remove redundant braces.
  • Don't sort dynamic symbol table (yet).
ikudrin marked 2 inline comments as done.Oct 20 2015, 2:15 PM
ruiu accepted this revision.Oct 20 2015, 2:20 PM
ruiu edited edge metadata.

LGTM with a nit.

ELF/OutputSections.cpp
698 ↗(On Diff #37916)

Early return before this 'else' to remove this 'else'.

This revision is now accepted and ready to land.Oct 20 2015, 2:20 PM
ruiu added a comment.Oct 20 2015, 2:26 PM

This comment is not directly related to this change (so you can ignore), but I noticed that the symbol handling in SymbolTableSection is very odd. We do call addSymbol only when includeInSymtab() is true for a symbol, but we basically discard that information and iterate over the symbol table again inside SymbolTableSection when writing an output (and call includeInSymtab() again so that the output is consistent). This needs to be straightened.

In D13911#271550, @ruiu wrote:

This comment is not directly related to this change (so you can ignore), but I noticed that the symbol handling in SymbolTableSection is very odd. We do call addSymbol only when includeInSymtab() is true for a symbol, but we basically discard that information and iterate over the symbol table again inside SymbolTableSection when writing an output (and call includeInSymtab() again so that the output is consistent). This needs to be straightened.

This patch fixes that behavior for global symbols.

ruiu added a comment.Oct 20 2015, 2:32 PM

Yes, that's awesome. Local symbols are handled differently, so it's probably a bit hard to remove that.

This revision was automatically updated to reflect the committed changes.