Add support for --build-id

[davidlattimore]

Right now the --build-id flag is ignored (see args.rs). It'd be nice if we can support it without significantly slowing down the linker. The good news is that the linker has complete flexibility over how it generates the build-id. i.e. it doesn't need to be computed the same way as other linkers compute it. All that matters is:

• It needs to change when any part of the output binary changes
• It needs to be deterministic - i.e. it shouldn't be randomly generated

Whether it changes if one of the input files changes, but in a way that doesn't affect the output is an open question. My feeling is that it's probably OK if it does change. That would allow hashing the input files plus the arguments. The alternative is hashing the output, but that means we need to wait until we've finished writing the output, which gives us somewhat limited scope for parallelism.

Depending on how fast hashing is, hashing the output might still be OK if it can be done in parallel with closing all the input files (which is surprisingly slow - run the linker with --time to see).

The first thing that's needed is to add the .note.gnu.build-id to the output sections that the linker is aware of. This currently requires changing a bunch of places. I'll appologise now that there are so many places to change. It's something I'd like to refactor at some point, while keeping an eye to make sure performance doesn't regress. Fortunately the tests will guide you if you miss any of those places.

Next, you'll need to decide which "file" is responsible for owning the build-id. Mostly likely either Internal (which should probably at some point be renamed to Prelude) or Epologue.

If the flag is set, allocate the required space to the .note.gnu.build-id section in layout.rs.

Lastly write the build-id into the allocated space in elf_writer.rs.

[VorpalBlade]

Depending on how fast hashing is, hashing the output might still be OK if it can be done in parallel with closing all the input files (which is surprisingly slow - run the linker with --time to see).

Unrelated to this issue, but have you considered any of:

• Using io-uring to close files async?
• Closing them concurrently from a thread pool?
• What if we leave them open and let the OS clean up on process exit?
• In the readme you also mention mold actually does work in a forked background process to avoid cleanup blocking the user, this could also be used by wild to deal with this i presume.

(Sorry to hijack the issue, but those ideas just came up as solutions to that subproblem.)