ld64 automatically renames many sections depending on output type and assorted flags. Here, we implement the most common configs. We can add more obscure flags and behaviors as needed.
Depends on D101393
Paths 
  |  Differential  D101395  
[lld-macho] Implement builtin section renaming ClosedPublic Authored by gkm on Apr 27 2021, 12:50 PM. 
Details 
 Summary ld64 automatically renames many sections depending on output type and assorted flags. Here, we implement the most common configs. We can add more obscure flags and behaviors as needed. Depends on D101393 
Diff Detail 
 
Unit TestsFailed 
 Event Timelinegkm added a child revision: D100818: [lld-macho] Implement branch-range-extension thunks.Apr 27 2021, 12:51 PM Comment Actions I think we should implement features on an as-needed basis. E.g. we aren't likely to support MH_KEXT_BUNDLE or MH_DYLINKER any time in the near future, so I don't think adding code for them is worthwhile. Do we have use cases for -data_const and -text_exec? Also, what exactly are shared regions? Comment Actions 
 Done. 
 
 
 
 
 
 Comment Actions Yeah keeping -data_const makes sense. Thanks for removing the rest :) 
 This revision is now accepted and ready to land.May 3 2021, 3:35 PM gkm added inline comments. Closed by commit rG27b426b0c8ab: [lld-macho] Implement builtin section renaming (authored by gkm).  ·  Explain WhyMay 3 2021, 9:47 PM This revision was automatically updated to reflect the committed changes. 
Revision Contents 
 
 
Diff 341059 lld/MachO/Config.h
 lld/MachO/Driver.cpp
 lld/MachO/MergedOutputSection.h
 lld/MachO/MergedOutputSection.cpp
 lld/MachO/Options.td
 lld/MachO/Writer.cpp
 lld/test/MachO/builtin-rename.s
 lld/test/MachO/load-command-sequence.s
 lld/test/MachO/local-got.s
 lld/test/MachO/x86-64-relocs.s
 lld/test/MachO/x86-64-stubs.s
  | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Our implementation does so too, right? Would be good to make that explicit... also I think this comment would make more sense at the point where we invoke initializeSectionRenameMap to highlight that we are calling it before handling OPT_rename_section