roc/crates/linker
jecaro d21ea2ea83
Fix zig_host_app on NixOS
That's a problem with the dynamic loader:
https://discourse.nixos.org/t/no-such-file-of-directory-when-trying-to-execute-binary-file/6150

When linking `libapp.so` with `host.zig`, zig puts in the binary the
standard path for the dynamic loader on linux:
`/lib64/ld-linux-x86-64.so.2`

However in NixOS, that file is somewhere else in the nix store (see:
https://nixos.wiki/wiki/Packaging/Binaries#The_Dynamic_Loader). Removing
the `-target` switch makes zig uses the host target for linking and puts
the right path to the dynamic loader in the resulting binary. As we want
to execute that binary file in this test, it makes sense to use the
default target anyway.

Note that this is relevant for the creation of the binary only. For the
creation of the object file, it doesn't really matter. But I removed the
`-target` switch as well there for consistency.

Fix #4180
2023-11-21 11:12:31 +01:00
..
src Fix zig_host_app on NixOS 2023-11-21 11:12:31 +01:00
Cargo.toml Parameterize program solving on a FunctionKind 2023-07-12 13:53:50 -05:00
dynhost_benchmarks_elf64 add an example dynhost elf file 2022-08-27 12:16:28 +02:00
dynhost_benchmarks_windows.exe update the dynhost file (dll name is now different) 2022-10-23 21:30:52 +02:00
README.md Kevin Gillette: markdown typo fixes 2023-04-10 14:07:03 -06:00

The Roc Surgical Linker

This linker has the goal of being extremely slim lined and fast. It is focused on the scope of only linking platforms to Roc applications. This restriction enables ignoring most of linking.

General Overview

This linker is run in 2 phases: preprocessing and surgical linking.

Platform Preprocessor

  1. Dynamically link the platform to a dummy Roc application dynamic library
  2. Create metadata related to Roc dynamically linked functions
    • Symbols that need to be redefined
    • Call locations that need to be modified for each symbol
    • Locations of special roc functions (roc_alloc, roc_dealloc, builtins, etc)
  3. Modify the main executable to no longer be dynamically link
    • Delete dependency on dynamic library
    • Remove symbols from the dynamic table (maybe add them to the regular table?)
    • Delete GOT and PLT entries
    • Remove relocations from the dynamic table
    • Add extra header information about new text and data section at end of file

Surgical Linker

  1. Build off of preprocessed platform
  2. Append text and data of application, dealing with app relocations
  3. Surgically update all call locations in the platform
  4. Surgically update call information in the application (also dealing with other relocations for builtins)

TODO (In a lightly prioritized order)

  • Add Macho support
    • Honestly should be almost exactly the same code. This means we likely need to do a lot of refactoring to minimize the duplicate code. The fun of almost but not quite the same.
  • Add PE support
    • As a prereq, we need roc building on Windows (I'm not sure it does currently).
    • Definitely a solid bit different than elf, but hopefully after refactoring for Macho, won't be that crazy to add.
  • Look at enabling completely in memory linking that could be used with roc run and/or roc repl
  • Look more into rust hosts and keeping certain functions. Currently I just disabled linker garbage collection. This works but adds 1.2MB (40%) to even a tiny app. It may be a size issue for large rust hosts. Roc, for reference, adds 13MB (20%) when linked without garbage collection.
  • Add a feature to the compiler to make this linker optional.