[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