[GHC] #12735: Evaluate the feasibility of using lld for linking
#12735: Evaluate the feasibility of using lld for linking -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Our runtime system's linker a represents a significant amount of rather tricky code. We have in the past attempted to jettison it by moving to dynamic linking, although this lead to its own set of issues (see [DynamicLinkingDebate]). Another approach would be to let someone else implement our linker for us. While in the past linkers were rather monolithic things, today there exists LLVM's `lld` [http://lld.llvm.org/|linker]. Like the other LLVM projects, its design is quite modular and can be used as a library. It seems likely that it could be made to do our bidding with enough effort. The question, of course, is whether this effort is greater than the effort we currently spend on the runtime linker. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12735 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12735: Evaluate the feasibility of using lld for linking -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -4,1 +4,1 @@ - [DynamicLinkingDebate]). + [[DynamicLinkingDebate]]). New description: Our runtime system's linker a represents a significant amount of rather tricky code. We have in the past attempted to jettison it by moving to dynamic linking, although this lead to its own set of issues (see [[DynamicLinkingDebate]]). Another approach would be to let someone else implement our linker for us. While in the past linkers were rather monolithic things, today there exists LLVM's `lld` [http://lld.llvm.org/|linker]. Like the other LLVM projects, its design is quite modular and can be used as a library. It seems likely that it could be made to do our bidding with enough effort. The question, of course, is whether this effort is greater than the effort we currently spend on the runtime linker. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12735#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12735: Evaluate the feasibility of using lld for linking -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): I would like to investigate a different approach: split the RTS linker as a C library that can be used by other projects, and which exposes a C API. GHC would then depend on this library. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12735#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12735: Evaluate the feasibility of using lld for linking -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:2 dobenour]:
I would like to investigate a different approach: split the RTS linker as a C library that can be used by other projects, and which exposes a C API. GHC would then depend on this library.
I actually had a look at the `lld` codebase a few weeks ago and my initial impressions were that it isn't terribly well-suited to be used as a runtime linker. I offers a lot of parsing and relocation logic, but it lacks any support for managing mappings and the like. Consequently, I think the option that you suggest (which erikd has also advocated for in the past) is the only way forward. I would love to see it happen, but it will take some time. Currently our runtime linker is sorely in need of tests; this makes any sort of large-scale refactoring quite risky. `lld`'s testsuite may be a good source of inspiration (and perhaps even tests!) for fixing this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12735#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC