On Wed, 20 Oct 2021 12:23:28 GMT, Stefan Karlsson <[email protected]> wrote:
>> We encountered the following linking error when trying to build Generational
>> ZGC on Windows:
>>
>> jvm.exp : error LNK2001: unresolved external symbol "const
>> ZBasicOopIterateClosure<class <lambda_9767402e468f9fc654281195f9700e48>
>> >::`vftable'"
>> (??_7?$ZBasicOopIterateClosure@V<lambda_9767402e468f9fc654281195f9700e48>@@@@6B@)
>>
>>
>> I narrowed this down to a simple reproducer, which doesn't link when built
>> through the HotSpot build system:
>>
>> #include <functional>
>> std::function<void()> = [](){};
>>
>>
>> I found that we have a line in our make files that filters out symbols that
>> contain the string vftable (though it checks the mangled name, so a bit hard
>> to find):
>>
>> else ifeq ($(call isTargetOs, windows), true)
>> DUMP_SYMBOLS_CMD := $(DUMPBIN) -symbols *.obj
>> FILTER_SYMBOLS_AWK_SCRIPT := \
>> '{ \
>> if ($$7 ~ /??_7.*@@6B@/ && $$7 !~ /type_info/) print $$7; \
>> }'
>>
>>
>> The following line prints the vftable symbol if it doesn't contain the
>> string 'type_info':
>> if ($$7 ~ /??_7.*@@6B@/ && $$7 !~ /type_info/) print $$7;
>>
>> The printed values are added to a list of symbols that get filtered out of
>> the mapfile, which is then passed to the linker.
>>
>> I can get the code to link if I add a second exception for vftable symbols
>> containing the string 'lambda':
>> if ($$7 ~ /??_7.*@@6B@/ && $$7 !~ /type_info/ && $$7 !~ /lambda/) print $$7;
>>
>> I did an additional experiment where I completely removed this filtering of
>> vftable symbols. When I did that the linker complained that we used more
>> than 64K symbols.
>
> Stefan Karlsson has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Fix typo
Looks good to me!
-------------
Marked as reviewed by pliden (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/6030
