[lld] lld: Add initial support for GNU LTO format (PR #157175)

Tulio Magno Quites Machado Filho via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 10 14:17:58 PDT 2025


================
@@ -29,32 +30,96 @@
 
 namespace llvm::lto {
 class LTO;
+struct SymbolResolution;
 }
 
 namespace lld::elf {
 struct Ctx;
 class BitcodeFile;
+class ELFFileBase;
 class InputFile;
+class IRFile;
+class BinaryFile;
+
+class IRCompiler {
+protected:
+  Ctx &ctx;
+  llvm::DenseSet<StringRef> thinIndices;
+  llvm::DenseSet<StringRef> usedStartStop;
+  virtual void addObject(IRFile &f,
+                         std::vector<llvm::lto::SymbolResolution> &r) = 0;
+
+public:
+  IRCompiler(Ctx &ctx) : ctx(ctx) {}
+  virtual ~IRCompiler() {};
+  void add(IRFile &f);
+  virtual SmallVector<std::unique_ptr<InputFile>, 0> compile() = 0;
+};
+
+class BitcodeCompiler : public IRCompiler {
+protected:
+  void addObject(IRFile &f,
+                 std::vector<llvm::lto::SymbolResolution> &r) override;
 
-class BitcodeCompiler {
 public:
   BitcodeCompiler(Ctx &ctx);
-  ~BitcodeCompiler();
+  ~BitcodeCompiler() {};
 
-  void add(BitcodeFile &f);
-  SmallVector<std::unique_ptr<InputFile>, 0> compile();
+  void add(BinaryFile &f);
+  SmallVector<std::unique_ptr<InputFile>, 0> compile() override;
 
 private:
-  Ctx &ctx;
   std::unique_ptr<llvm::lto::LTO> ltoObj;
   // An array of (module name, native relocatable file content) pairs.
   SmallVector<std::pair<std::string, SmallString<0>>, 0> buf;
   std::vector<std::unique_ptr<MemoryBuffer>> files;
   SmallVector<std::string, 0> filenames;
-  llvm::DenseSet<StringRef> usedStartStop;
   std::unique_ptr<llvm::raw_fd_ostream> indexFile;
-  llvm::DenseSet<StringRef> thinIndices;
 };
+
+#if LLD_ENABLE_GNU_LTO
+#include <plugin-api.h>
----------------
tuliom wrote:

GPL does not distinguish between static linking and dynamic linking. With that said, I agree with you that the LLD produced when both `LLD_LINK_GPL3` and `LLD_ENABLE_GNU_LTO` are defined will be GPL too.  That's why I'm following the suggestion to use 2 CMake variables in order to reduce the chance of unintentional linkage to GPLv3.

Regarding copying the contents from `plugin-api.h`: this will require to keep the LLVM file in sync with Binutils from time to time. This is not needed if we reuse the system-provided one.
I don't have a strong preference, though.

https://github.com/llvm/llvm-project/pull/157175


More information about the llvm-commits mailing list