rui314 / mold

Mold: A Modern Linker 🦠
MIT License
14.11k stars 463 forks source link

Consider a compatibility bug enumeration #397

Closed riking closed 2 years ago

riking commented 2 years ago

This issue is written in response to seeing e67f460bfdf4a6aa5221efdf0f3547c05b3a2152 in the release notes.

Instead of writing ad-hoc detectors in several spots in the codebase, create a centralized enumeration of relevant compatibility bugs, query the type and version of the linker plugin at setup, and use this to determine behavior switching.

This has the significant benefit that you can set an "ends at version" for compatibility bugs fixed upstream.

For a concrete example of what this looks like, take a look at Dolphin (GPLv3+): https://github.com/dolphin-emu/dolphin/commit/9b4e5b00ee7393303285c2010c409244145fee40 DriverDetails.h DriverDetails.cpp

  // It looks like GCC doesn't need fd after claim_file_hook() while
  // LLVM needs it and takes the ownership of fd. To prevent "too many
  // open files" issue, we close fd only for GCC. <strike>This is ugly, though.</strike>
  if (has_bug(ctx, BUG_CLAIM_FILE_HOOK_NEEDS_CLOSE)) {
    close(mf2->fd);
    mf2->fd = -1;
  }
rui314 commented 2 years ago

I don't know if this can simplify the codebase. These are not bugs but more like differences between LLVM and GCC, and there aren't too many differences. We need to handle only a few. And that is compartmented in lto.cc nicely, so it's an implementation detail only people who read that file care about. lto.cc is only ~700 lines long.