[PATCH] D119049: [LLD] Allow usage of LLD as a library

Zhuoran Yin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 24 13:08:34 PST 2023


jerryyin added a comment.

> It seems that there's no universal solution for overriding a symbol in a LIB by a symbol in another LIB...simply implementing the missing drivers with the LLD_IMPLEMENT_SHALLOW_DRIVER macro

Thanks for letting me know, sounds like a fair solution.



================
Comment at: lld/Common/DriversMain.cpp:163-172
+    if (f == MinGW)
+      return mingw::link;
+    else if (f == Gnu)
+      return elf::link;
+    else if (f == WinLink)
+      return coff::link;
+    else if (f == Darwin)
----------------
I have a naïve question to ask:
 - In my limited knowledge, previously `lldELF` is dependent on `lldCommon` target. `lld.cpp` would compile just fine because its target is an executable.
 - Now, since `DriversMain.cpp` become part of `lldCommon`, and in the implementation of `DriversMain,cpp`, we start to invoke those specific link target, it implicitly requires, for example, `lld::elf::link` to be available before `lldCommon` is compiled. In other words, `lldCommon` is dependent on `lldELF`. 

Did we just have a cyclic dependency here? And if it is, do you need to move the `lldMain()` and `safeLldMain()` into their own independent target such that we can avoid the existence of such a cycle in the compilation?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119049/new/

https://reviews.llvm.org/D119049



More information about the llvm-commits mailing list