[PATCH] D89561: [MC] Adjust StringTableBuilder for linked Mach-O binaries

[Shoaib Meenai via Phabricator via llvm-commits]

smeenai added a comment.

@mtrent, do you have the historical context for why ld64 adds a leading space to the string table? The relevant lines from its code are:

  // burn first byte of string pool (so zero is never a valid string offset)
  _currentBuffer[_currentBufferUsed++] = ' ';
  // make offset 1 always point to an empty string
  _currentBuffer[_currentBufferUsed++] = '\0';

However, the Mach-O documentation <https://web.archive.org/web/20090901205800/http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html> says:

> A union that holds an index into the string table, `n_strx`. To specify an empty string (`""`), set this value to 0.

which suggests that the first byte of the string table should be the 0 byte and not the space.

`mach-o/nlist.h` is a bit more ambiguous. It says:

  /*
   * Symbols with a index into the string table of zero (n_un.n_strx == 0) are
   * defined to have a null, "", name.  Therefore all string indexes to non null
   * names must not have a zero string index.  This is bit historical information
   * that has never been well documented.
   */

which could be interpreted as either "an `n_strx` of 0 should mean the empty string" (as above), or "an `n_strx` of 0 will always be interpreted as the empty string //regardless of the string table's contents//" (in which case ld64 is free to put what it wants as the first byte of the string table).

Is ld64 trying to reserve an `n_strx` of 0 as invalid in some way and distinguish it from an `n_strx` of 1 meaning the empty string?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89561/new/

https://reviews.llvm.org/D89561