[PATCH] D132560: [lld-macho] Add initial support for chained fixups

Nico Weber via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 24 12:07:31 PDT 2022


thakis added a comment.

Very cool. I haven't really looked at it yet. (I'll play with it once the prerequisites are landed; fewer `patch` invocations then :) )



================
Comment at: lld/MachO/Driver.cpp:1478
+  if (config->makeChainedFixups && args.hasArg(OPT_no_pie))
+    error("-fixup_chains is incompatible with -no_pie");
+
----------------
Emit a diag if makeChainedFixups is true but the deployment target (`config->platformInfo.minimum`) is too old to support them.

Below are no action required:

- Idea guying, not for this patch (and likely never): What does dyld do if a binary has both bind opcodes and chained fixups? Does it use the opcodes on older macOS (or iOS or…) versions but the fixups on newer versions?

- nit: I'd s/makeChainedFixups/emitFixupChains/ (to be closer to the flag name), but meh. Oh, you made it match the section, not the flag. Even more meh then, but s/make/emit/ in the variable still seems marginally better to me.


================
Comment at: lld/MachO/SyntheticSections.h:664
+// first fixup of each page; the rest can be found by walking the chain using
+// the offset that is embedded in each entry.
+//
----------------
Maybe mention that the motivation is that text pages can be relocated lazily at page-in time, and that they don't become dirty and can be discarded and paged in again as needed. That is, the benefits are:

- somewhat faster startup (no need to do all relocs at app startup)
- more memory-efficient, since text pages can be discarded

That motivates why the fixups are per-page and then chained (since that's how they're accessed at page-in time).


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

https://reviews.llvm.org/D132560



More information about the llvm-commits mailing list