[PATCH] D147544: [BOLT] Move from RuntimeDyld to JITLink

[Job Noorman via Phabricator via llvm-commits]

jobnoorman added a comment.

Thanks for your comments, @lhames!

> If you only need static linking, wouldn't lld be a better fit than the JIT APIs?

I think you're right, at least in theory. In fact, when looking into this JITLink port, I briefly considered using lld. I decided against it for the following reasons:

- lld's API is rather primitive: it's basically just a wrapper around calling ld.lld's main function with command-line arguments. This means that, for example, inputs always need to be written out to disk and cannot be processed completely in memory (as BOLT now does). We would also need to write linker scripts on-the-fly to support custom section remapping. This is probably not a huge problem but feels a bit inelegant.
- I felt this would need a //huge// rewrite of BOLT's logic. BOLT doesn't relink all code. Some parts are simply copied over from the input file to the output. References from the relinked code to other parts of the binary are resolved using a custom symbol lookup. There's quite some custom logic for reassembling the final ELF file (handling GOTs, PLTs, eh_frame,...). etc. I wasn't confident this could easily be adapted to the use of lld.

Of course, these are not good reasons for why BOLT //has// to use a JIT linker. However, since my main goal for this patch is to move BOLT away from the deprecated RuntimeDyld library, I felt like switching to JITLink was the easier and more pragmatic choice.

My assessment might be a bit off, though, and maybe there are good reasons for BOLT to use a JIT linker. I'd be very interested in hearing the opinions of the BOLT devs on this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147544