[llvm-dev] LLD doesn't handle globals with appending linkage

Gleb Popov via llvm-dev llvm-dev at lists.llvm.org
Thu Feb 20 03:16:02 PST 2020


On Tue, Feb 18, 2020 at 12:28 PM Gleb Popov <6yearold at gmail.com> wrote:

> Hello.
>
> I'm posting this question here, because there seem to be no LLD-specific
> mailing list. Sorry in advance if this is wrong one.
>
> I compile two C source with following command:
>
> clang -flto -o %name.bc %name.c
>
> LLVM is augmented with my custom pass, which amongst other things create a
> global with appending linkage:
>
> @myvar = appending constant [1 x [1 x i8]*] ...
>
> I also have another pass plugged into LTO pipeline, which turns this
> global into internal one in the final module. I was hoping that LLD would
> first link bitcodes like llvm-link, appending @myvar's from both modules
> into a single one, then run my pass, and only then perform linking at
> object level.
>
> However, LLD complains about duplicated symbol "myvar" and doesn't even
> run any passes.
>
> I've tracked the problem down to BitcodeFile::parse() function from
> https://github.com/llvm/llvm-project/blob/master/lld/COFF/InputFiles.cpp#L918
> - it doesn't take linkage type into account.
>
> Can anything be done about this problem? Or was my approach broken from
> the beginning?
>
> Thanks in advance.
>


The following patch has fixed the problem for me:

diff --git a/llvm/lib/Object/ModuleSymbolTable.cpp
b/llvm/lib/Object/ModuleSymbolTable.cpp
index 33ce7d8109f..d1d74fa54bf 100644
--- a/lib/Object/ModuleSymbolTable.cpp
+++ b/lib/Object/ModuleSymbolTable.cpp
@@ -201,7 +201,7 @@ uint32_t ModuleSymbolTable::getSymbolFlags(Symbol S)
const {
     Res |= BasicSymbolRef::SF_Executable;
   if (isa<GlobalAlias>(GV))
     Res |= BasicSymbolRef::SF_Indirect;
-  if (GV->hasPrivateLinkage())
+  if (GV->hasPrivateLinkage() || GV->hasAppendingLinkage())
     Res |= BasicSymbolRef::SF_FormatSpecific;
   if (!GV->hasLocalLinkage())
     Res |= BasicSymbolRef::SF_Global;

Is it a sane approach? Can it be upstreamed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200220/47493955/attachment.html>


More information about the llvm-dev mailing list