[lld] Alternate name referring another alternate name is not resolved

[vahur]

Steps to reproduce on Windows:

test.c

#pragma comment(linker, "/alternatename:x=y")
#pragma comment(linker, "/alternatename:y=puts")

extern int x(const char *str);

int main(void) {
    x("Hello");
    return 0;
}

Compile and link:

clang-cl /c test.c
lld-link /OUT:test.exe /SUBSYSTEM:console test.obj

It works with lld-link <=20 and MS link.exe, but fails with lld-link 21.1.1:

lld-link: error: undefined symbol: x
>>> referenced by test.obj:(main)

I think it's caused by this commit: ac31d64. If I roll back that commit for SymbolTable.cpp, linking succeeds again.

[llvmbot]

@llvm/issue-subscribers-lld-coff

Author: Vahur Sinijärv (vahur)

Steps to reproduce on Windows:

test.c

#pragma comment(linker, "/alternatename:x=y")
#pragma comment(linker, "/alternatename:y=puts")

extern int x(const char *str);

int main(void) {
    x("Hello");
    return 0;
}

Compile and link:

clang-cl /c test.c
lld-link /OUT:test.exe /SUBSYSTEM:console test.obj

It works with lld-link <=20 and MS link.exe, but fails with lld-link 21.1.1:

lld-link: error: undefined symbol: x
>>> referenced by test.obj:(main)

I think it's caused by this commit: ac31d64. If I roll back that commit for SymbolTable.cpp, linking succeeds again.

[aganea]

@cjacek

[cjacek]

I think that while my commit made such a chain less likely to work, it was never fully supported. It depends on the order in which we process altnames, so if you replaced "y" with "w" in this example, it would already have been broken in previous LLD versions.

This patch should restore the functionality: cjacek@eb922cf. It's not quite optimal, but we probably want a more complete solution to properly support altname chains anyway. I’m not yet sure how to implement that.

[vahur]

@cjacek If by replace y with w you mean to add one more altname to the chain, like:

#pragma comment(linker, "/alternatename:x=y")
#pragma comment(linker, "/alternatename:y=w")
#pragma comment(linker, "/alternatename:w=puts")

then this does not work with MSVC linker either. Seems that an altname chain can have at most two links.

I tried your patch cjacek@eb922cf, it does indeed fix the issue. I can now build zig with clang-cl/llvm toolchain as MSVC replacement, which previously failed because of altname chains.

It deviates from MSVC linker though, as it can resolve longer chains, not sure if this is good or bad...
x->y->w->puts is resolved by lld-link now while MSVC link.exe gives "unresolved external symbol" error.

[cjacek]

In my previous comment I meant something like this:

#pragma comment(linker, "/alternatename:x=w")
#pragma comment(linker, "/alternatename:w=puts")

Depending on whether the middle symbol is processed before or after the first one in the chain, we hit different code paths (and they’re processed alphabetically). I think one of those paths has always been broken.

Thanks for the observation about the chain length limit, that’s an interesting detail. I experimented a bit further, and I get the impression that this mechanism isn’t well supported in MSVC either. For example, if you link your example with -entry:main (which effectively skips startup code and its dependencies), it fails to link on MSVC. I don’t see why that should affect whether it links or not.

I wrote a more reliable version of a potential fix:
cjacek@ec2d0fa

I’m not entirely happy with it, it feels a bit special-cased. It now works regardless of symbol order and supports chains of length two. This may require iterating over the alternate names multiple times, so I optimized that by removing entries we know we won’t need. A better idea would definitely be welcome. We could maybe introduce a new symbol type for alternate names, but that would be quite an invasive change to the symbol table.