This is PR30312. Info from bug page:
Both of these symbols demangle to abc::abc():
_ZN3abcC1Ev
_ZN3abcC2Ev
(These would be abc's complete object constructor and base object constructor, respectively.)
however with "abc::abc()" in the version script only one of the two receives the symbol version.
Patch fixes that.
It uses testcase created by Ed Maste (D24306).
Differential revision: https://reviews.llvm.org/D24336
llvm-svn: 281318
Summary: This test fails if you're building with BUILD_SHARED_LIBS because the LLVM libraries are found via @rpath. Symlinking instead of copying should be sufficiently robust for the test case.
Reviewers: llvm-commits
Subscribers: davide
Differential Revision: https://reviews.llvm.org/D24476
llvm-svn: 281271
Similarly to what was done in r280791 for llvm/.
This should fix a bunch of failures I saw while
trying a BUILD_SHARED_LIBS build on MacOS.
Still there are some failures, but this is a step
forward.
Thanks a lot to Chris Bieneman for the suggested
fix (in PR30345)
llvm-svn: 281256
Having two directories with the same name modulo case does not work well
on Windows. The new test/elf directory was added in r281108. I assume
the intention was to add the test file to the existing test/ELF dir.
llvm-svn: 281115
Implemented by building an ELF file in memory.
elf, default, and binary match gold behavior.
Differential Revision: https://reviews.llvm.org/D24060
llvm-svn: 281108
Although the GUID seems to be stable across test runs now, it seems to be
unstable across hosts. Lets be a bit more lax about the reading of the RSDS
record.
llvm-svn: 281083
Change the way we calculate the build id to use MD5 to give reproducible build
ids. Previously we would generate random bytes for the build id GUID.
llvm-svn: 281079
Fixed code that was not checked before on windows for me, because of testcases that are
disabled on that platform atm.
Inital commit message:
"[ELF] - Versionscript: do not treat non-wildcarded names as wildcards."
Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:
GLIBCXX_3.4 {
extern "C++" {
"aaa*"
}
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:
extern "C++" {
"operator delete[](void*)";
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D24229
llvm-svn: 281049
Fixed code that was not checked by testcases that are disabled on windows.
Inital commit message:
"[ELF] - Versionscript: do not treat non-wildcarded names as wildcards."
Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:
GLIBCXX_3.4 {
extern "C++" {
"aaa*"
}
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:
extern "C++" {
"operator delete[](void*)";
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D24229
llvm-svn: 281045
Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:
GLIBCXX_3.4 {
extern "C++" {
"aaa*"
}
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:
extern "C++" {
"operator delete[](void*)";
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D24229
llvm-svn: 281038
Usually, options that are longer than one character can be preceded
either by "-" or "--", but options starting with "o" are exceptions
because they conflict with "-o" option. They have to be preceded by
"--".
llvm-svn: 281004
We still have to skip a token inside SEARCH_DIR() when -nostdlib is
specified. Previuosly, we didn't skip it, so it caused a parse error.
llvm-svn: 281001
lld differs from GNU ld in that it does not have a built-in default
target emulation. Emulation is always specified via the -m option, or
obtained from the object file(s) being linked. In most cases at least
one ELF object is included in the link, so the emulation is known.
When using lld's (not yet committed) -b binary support with -r, to
convert a binary file into an ELF object we do not have a known
emulation. The error message previously emitted in this case
"-m or at least a .o file required" is accurate but does not offer
much insight. Add text to the error message to give a hint why -m or an
object file is required.
Differential Revision: https://reviews.llvm.org/D24348
llvm-svn: 280989
A trailing _fbsd is stripped from emulation names, but if the result was
still not a valid emulation the error was somewhat confusing.
For example,
% ld.lld -m elf_amd64_fbsd
unknown emulation: elf_amd64
Use the original emulation name in error messages.
Differential Revision: https://reviews.llvm.org/D24357
llvm-svn: 280983
In the FreeBSD world x86_64 still has its original name, amd64. Accept
it as an alias.
Differential Revision: https://reviews.llvm.org/D24356
llvm-svn: 280982
This simplifies error handling as there is now only one place in the
code that needs to consider the possibility that the name is
corrupted. Before we would do it in every access.
llvm-svn: 280937
Absence of it caused a clang warning:
warning: 'lld:🧝:LinkerScriptBase' has virtual functions but non-virtual destructor [-Wnon-virtual-dtor]
At fact we don't need it here because do not destroy this object by
base pointer.
llvm-svn: 280916
This patch allows static linking of TLS code. To do that it fixes
GOT entries initialization.
If TLS-related GOT entry created for a preemptible symbol i.e. has
a corresponding dynamic relocation, leave the entry initialized by zero.
Write down adjusted TLS symbol's values otherwise. For the adjustments
calculation use offsets for thread-local storage.
https://www.linux-mips.org/wiki/NPTL
llvm-svn: 280914
Previous way of accessing templated methods was a bit bulky,
Patch introduces small interface based solution.
Differential revision: https://reviews.llvm.org/D23872
llvm-svn: 280910
GCC passes it by default on powerpc64 on FreeBSD. GNU ld claims "this
option is ignored for SVR4 compatibility", so we can ignore it too.
Differential Revision: https://reviews.llvm.org/D24313
llvm-svn: 280864
Rafael Espindola