[PATCH] D87199: [lld-macho] Implement support for PIC

Wed Sep 23 23:15:35 PDT 2020

smeenai added a subscriber: psmith.
smeenai added a comment.

In D87199#2264781 <https://reviews.llvm.org/D87199#2264781>, @int3 wrote:

>> but would any of this be easier if SyntheticSections were InputSections instead of OutputSections
>
> Maybe... we could make them InputSections and then generate unsigned relocations for each of their entries. There would be some additional overhead (e.g. the `addend` field would be useless) but it would allow us to handle the rebases in one place. One thing I'm not sure about is whether other architectures have an equivalent of `X86_64_RELOC_UNSIGNED` that can be used for this; it looks like arm64 does, but not sure about PPC (not that it really matters).
>
> There are other benefits to having SyntheticSections be InputSections: there would no longer be a need for the `SectionPointerUnion`, and `DSOHandle` could just be an ordinary `Defined` symbol.
>
> I actually can't think of many real downsides... do you have any in mind? That said, the current architecture is not terrible, and I'm inclined to work on implementing more features and pushing the refactoring till later.

I agree with refactoring later (not too much later, but it probably makes sense to at least get some experience with implementing other architectures first). We decided to make SyntheticSections be OutputSections back in https://reviews.llvm.org/D77893#inline-716459. We were debating why ELF makes them InputSections; it appears the main motivation for that design was to allow synthetic sections to be manipulated via linker scripts, which we don't need to support with Mach-O. We can decide what ultimately makes more sense when we have a bit more of the implementation completed though.

@psmith, in your talk on LLD's performance (https://archive.fosdem.org/2019/schedule/event/llvm_lld/), you mentioned something along the lines of LLD's synthetic sections being input sections (as opposed to output) significantly speeding up thunks (at the 25:10 mark). Would you be able to elaborate on why? We'll need to implement thunks when we add the ARM64 support, although our design will probably be closer to COFF's than ELF's (since we don't have linker scripts).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87199