r320770 made LLD handle invalid DSOs where local symbols were found in
the global part of the symbol table. Unfortunately, it didn't handle the
case where those local symbols were also undefined, and r326242 exposed
an assertion failure in that case. Just warn on that case instead of
crashing, by moving the local binding check before the undefined symbol
addition.
The input file for the test is crafted by hand, since I don't know of
any tool that would produce such a broken DSO. I also don't understand
what it even means for a symbol to be undefined but have STB_LOCAL
binding - I don't think that combination makes any sense - but we have
found broken DSOs of this nature that we were linking against. I've
included detailed instructions on how to produce the DSO in the test.
Differential Revision: https://reviews.llvm.org/D52815
llvm-svn: 343745
A test verifying that toc restores are properly inserted following recursive
calls, as well as briefly describing why they are needed.
Differential Revision: https://reviews.llvm.org/D52564
llvm-svn: 343729
When GNU tools create a weak alias, they produce a strong symbol
named .weak.<weaksymbol>.<relatedstrongsymbol>.
GNU ld allows many such weak alternatives for the same weak symbol, and
the linker picks the first one encountered.
This can't be reproduced by assembling from .s files, since llvm-mc
produces symbols named .weak.<weaksymbol>.default in these cases.
Differential Revision: https://reviews.llvm.org/D52601
llvm-svn: 343704
Three related changes:
1. link.exe uses the presence of main and wmain to decide if it should call
mainCRTStartup or wmainCRTStartup, even if /nodefaultlib is passed. For
compatibility, remove FindMain logic.
2. Default to the non-wide entrypoint if main is not found. This has two effects:
2a. In normal links, lld-link now prints
lld-link: error: undefined symbol: _main
>>> referenced by f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:78
>>> libcmt.lib(exe_main.obj):("int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ))
>>> referenced by f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283
>>> libcmt.lib(exe_main.obj):("int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ))
instead of
lld-link: error: entry point must be defined
This is arguably a better error message, since it now mentions that _main is
missing. (This matches link.exe's diagnostic in this case.)
2b. With /nodefautlib, we now default to mainCRTStartup if no main() is
present, again matching link.exe. This makes r337407 obsolete.
This means if you have a cc file containing both mainCRTStartup and
wmainCRTStartup and you pass /nodefaultlib /subsystem:console, lld-link will
now call mainCRTStartup, matching link.exe
3. Print a warning if both main and wmain are present, similar to link.exe's
LNK4067.
Differential Revision: https://reviews.llvm.org/D52832
llvm-svn: 343698
This stops testing the value of .rela.plt section offset.
Also makes _start global to eliminate
'cannot find entry symbol _start' warning.
llvm-svn: 343669
This is the fix for
"Bug 39104 - LLD links incorrect ELF executable if version script contains "local: *;"
(https://bugs.llvm.org/show_bug.cgi?id=39104).
The issue happens when we have non-PIC program call to function in a shared library.
(for example, the PR above has R_X86_64_PC32 relocation against __libc_start_main)
LLD converts symbol to Defined in that case with the use of replaceWithDefined()
The issue is that after above we create a broken relocation because do not
include the symbol into .dynsym.
That happens when the version script is used because we treat the symbol as
STB_LOCAL if the following condition match:
VersionId == VER_NDX_LOCAL && isDefined() and do not include it to
.dynsym because of that. Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D52724
llvm-svn: 343668
Imagine we have the following code:
int foo();
int main() { return foo(); }
It will crash if you try to compile it with
`clang -O0 -gdwarf-5 test.cpp -o test -g -fuse-ld=lld`
The crash happens inside the LLVM DWARF parser because LLD does not provide
the .debug_line_str section. At the same time for correct parsing and reporting,
we anyways need to provide this section from our side.
The patch fixes the issue.
llvm-svn: 343667
Summary:
This patch adds a new flag, --warn-ifunc-textrel, to work around a glibc bug. When a code with ifunc symbols is used to produce an object file with text relocations, lld always succeeds. However, if that object file is linked using an old version of glibc, the resultant binary just crashes with segmentation fault when it is run (The bug is going to be corrected as of glibc 2.19).
Since there is no way to tell beforehand what library the object file will be linked against in the future, there does not seem to be a fool-proof way for lld to give an error only in cases where the binary will crash. So, with this change (dated 2018-09-25), lld starts to give a warning, contingent on a new command line flag that does not have a gnu counter part. The default value for --warn-ifunc-textrel is false, so lld behaviour will not change unless the user explicitly asks lld to give a warning. Users that link with a glibc library with version 2.19 or newer, or does not use ifunc symbols, or does not generate object files with text relocations do not need to take any action. Other users may consider to start passing warn-ifunc-textrel to lld to get early warnings.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: grimar, MaskRay, markj, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D52430
llvm-svn: 343628
llvm rL343594: [ARM] Emmit data symbol
for constant pool data fixed a bug that ommited
required data symbols.
Such change breaked a test case in lld:
test/ELF/arm-thunk-largesection.s
llvm-svn: 343604
This uses the call graph profile embedded in the object files to construct the call graph.
This is read from a SHT_LLVM_CALL_GRAPH_PROFILE (0x6fff4c02) section as (uint32_t, uint32_t, uint64_t) tuples as (from symbol index, to symbol index, weight).
Differential Revision: https://reviews.llvm.org/D45850
llvm-svn: 343552
When GCC produces a jump table as part of a comdat function, the
jump table itself is produced as plain non-comdat rdata section. When
linked with ld.bfd, all of those rdata sections are kept, with
relocations unchanged in the sections that refer to discarded comdat
sections.
This has been observed with at least GCC 5.x and 7.x.
Differential Revision: https://reviews.llvm.org/D52600
llvm-svn: 343422
With LTO when and undefined function (with a known signature)
in replaced by a defined bitcode function we were loosing the
signature information (since bitcode functions don't have
signatures).
With this change we preserve the original signature from the
undefined function and verify that the post LTO compiled
function has the correct signature.
This change improves the error handling in the case where
there is a signature mismatch with a function defined in
a bitcode file.
Differential Revision: https://reviews.llvm.org/D50721
llvm-svn: 343340
In a very recent change I introduced a --no-export-default flag
but after conferring with others it seems that this feature already
exists in gnu GNU ld and lld in the form the --export-dynamic flag
which is off by default.
This change replaces export-default with export-dynamic and also
changes the default to match the traditional linker behaviour.
Now, by default, only the entry point is exported. If other symbols
are required by the embedder then --export-dynamic or --export can
be used to export all visibility hidden symbols or individual
symbols respectively.
This change touches a lot of tests that were relying on symbols
being exported by default. I imagine it will also effect many
users but do think the change is worth it match of the traditional
behaviour and flag names.
Differential Revision: https://reviews.llvm.org/D52587
llvm-svn: 343265
Add REQUIRES: x86 to pdb-debug-f.s as this is causing the Arm and
AArch64 buildbots to fail as they do not have the x86 backend.
Differential Revision: https://reviews.llvm.org/D52606
llvm-svn: 343196
Summary:
lld already gives later -z options precedence in getZFlag().
This matches the behavior of ld.bfd and ld.gold, where later options
override earlier ones. (I tested with -z max-page-size and -z stack-size.)
Reviewers: ruiu, espindola, grimar
Reviewed By: ruiu, grimar
Subscribers: grimar, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D52526
llvm-svn: 343145
Summary:
An AArch64 LE relocation is a positive ("variant 1") offset. This
relocation is used to write the upper 12 bits of a 24-bit offset into an
add instruction:
add x0, x0, :tprel_hi12:v1
The comment in the ARM docs for R_AARCH64_TLSLE_ADD_TPREL_HI12 is:
"Set an ADD immediate field to bits [23:12] of X; check 0 <= X < 2^24."
Reviewers: javed.absar, espindola, ruiu, peter.smith, zatrazz
Reviewed By: ruiu
Subscribers: emaste, arichardson, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D52525
llvm-svn: 343144
This is https://bugs.llvm.org//show_bug.cgi?id=38919.
Currently, LLD may report "unsupported relocation target while parsing debug info"
when parsing the debug information.
At the same time LLD does that for zeroed R_X86_64_NONE relocations,
which obviously has "invalid" targets.
The nature of R_*_NONE relocation assumes them should be ignored.
This patch teaches LLD to stop reporting the debug information parsing errors for them.
Differential revision: https://reviews.llvm.org/D52408
llvm-svn: 343078
This involves adding more generic list of symbol suffixes/prefixes
to ignore for autoexport; adding a few other entries to these lists
as well from the corresponding lists in binutils.
Differential Revision: https://reviews.llvm.org/D52382
llvm-svn: 343070
Don't assume that the IAT chunk will be a DefinedImportData, it can
just as well be a DefinedRegular for gnu import libraries.
Differential Revision: https://reviews.llvm.org/D52381
llvm-svn: 343069
These option control weather or not symbols marked as visibility
default are exported in the output binary.
By default this is true, but emscripten prefers to control the
exported symbol list explicitly at link time and ignore the
symbol attributes.
Differential Revision: https://reviews.llvm.org/D52003
llvm-svn: 343034
This is a feature that MS link.exe lacks; it currently errors out on
such relocations, just like lld did before.
This allows linking clang.exe for ARM - practically, any image over
16 MB will likely run into the issue.
Differential Revision: https://reviews.llvm.org/D52156
llvm-svn: 342962
Summary:
Currently we are pointing all debug information that refer removed function code
to the beginning of the code section (offset = 0). A debugger may want to
resolve code offset to the debug information, which will collide with offsets
of the live functions.
Moving offsets of dead functions outside code section range.
Reviewers: sbc100
Reviewed By: sbc100
Subscribers: dblaikie, ruiu, alexcrichton, dschuff, aprantl, jgravelle-google, aheejin, sunfish, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D49446
llvm-svn: 342930
Implement final argument precedence if multiple /debug arguments are passed on the command-line to match expected link.exe behavior.
Support /debug:none and emit warning for /debug:fastlink with automatic fallback to /debug:full.
Emit error if last /debug:option is unknown.
Emit warning if last /debugtype:option is unknown.
https://reviews.llvm.org/D50404
llvm-svn: 342894
GNU binutils import libraries aren't the same kind of short import
libraries as link.exe and LLD produce, but are a plain static library
containing .idata section chunks. MSVC link.exe can successfully link
to them.
In order for imports from GNU import libraries to mix properly with the
normal import chunks, the chunks from the existing mechanism needs to
be added into named sections like .idata$2.
These GNU import libraries consist of one header object, a number of
object files, one for each imported function/variable, and one trailer.
Within the import libraries, the object files are ordered alphabetically
in this order. The chunks stemming from these libraries have to be
grouped by what library they originate from and sorted, to make sure
the section chunks for headers and trailers for the lists are ordered
as intended. This is done on all sections named .idata$*, before adding
the synthesized chunks to them.
Differential Revision: https://reviews.llvm.org/D38513
llvm-svn: 342777
Summary:
As for x86_64, the default image base for AArch64 and i386 should be
aligned to a superpage appropriate for the architecture.
On AArch64, this is 2 MiB, on i386 it is 4 MiB.
Reviewers: emaste, grimar, javed.absar, espindola, ruiu, peter.smith, srhines, rprichard
Reviewed By: ruiu, peter.smith
Subscribers: jfb, markj, arichardson, krytarowski, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D50297
llvm-svn: 342746
The access sequence for global variables in the medium and large code models use
2 instructions to add an offset to the toc-pointer. If the offset fits whithin
16-bits then the instruction that sets the high 16 bits is redundant.
This patch adds the --toc-optimize option, (on by default) and enables rewriting
of 2 instruction global variable accesses into 1 when the offset from the
TOC-pointer to the variable (or .got entry) fits in 16 signed bits. eg
addis %r3, %r2, 0 --> nop
addi %r3, %r3, -0x8000 --> addi %r3, %r2, -0x8000
This rewriting can be disabled with the --no-toc-optimize flag
Differential Revision: https://reviews.llvm.org/D49237
llvm-svn: 342602
Summary:
For --pack-dyn-relocs=android, finalizeSections calls
LinkerScript::assignAddresses and
AndroidPackedRelocationSection::updateAllocSize in a loop,
where assignAddresses lays out the ELF image, then updateAllocSize
determines the size of the Android packed relocation table by encoding it.
Encoding the table requires knowing the values of relocation addends.
To get the addend of a TLS relocation, updateAllocSize can call getSymVA
on a TLS symbol before setPhdrs has initialized Out::TlsPhdr, producing an
error:
<file> has an STT_TLS symbol but doesn't have an SHF_TLS section
Fix the problem by initializing Out::TlsPhdr immediately after the program
headers are created. The segment's p_vaddr field isn't initialized until
setPhdrs, so use FirstSec->Addr, which is what setPhdrs would use.
FirstSec will typically refer to the .tdata or .tbss output section, whose
(tentative) address was computed by assignAddresses.
Android currently avoids this problem because it uses emutls and doesn't
support ELF TLS. This problem doesn't apply to --pack-dyn-relocs=relr
because SHR_RELR only handles relative relocations without explicit addends
or info.
Fixes https://bugs.llvm.org/show_bug.cgi?id=37841.
Reviewers: ruiu, pcc, chh, javed.absar, espindola
Subscribers: emaste, arichardson, llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D51671
llvm-svn: 342432
A General-dynamic tls access can be written using a R_PPC64_TLSGD16 relocation
if the target got entry is within 16 bits of the TOC-base. This patch adds
support for R_PPC64_TLSGD16 by relaxing it the same as a R_PPC64_GOT_TLSGD16_LO.
Differential Revision: https://reviews.llvm.org/D52055
llvm-svn: 342411
dllimported symbols go through an import stub that's called __imp_ followed by
the name the stub points to. Make that work.
Differential Revision: https://reviews.llvm.org/D52145
llvm-svn: 342401
Previously, lld-link would use a random byte sequence as the PDB GUID. Instead,
use a hash of the PDB file contents.
To not disturb llvm-pdbutil pdb2yaml, the hash generation is an opt-in feature
on InfoStreamBuilder and ldb/COFF/PDB.cpp always sets it.
Since writing the PDB computes this ID which also goes in the exe, the PDB
writing code now must be called before writeBuildId(). writeBuildId() for that
reason is no longer included in the "Code Layout" timer.
Since the PDB GUID is now a function of the PDB contents, the PDB Age is always
set to 1. There was a long comment above loadExistingBuildId (now gone) about
how not changing the GUID and only incrementing the age was important, but
according to the discussion in PR35914 that comment was incorrect.
Differential Revision: https://reviews.llvm.org/D51956
llvm-svn: 342334
For this, add a few toString() calls when printing the "undefined symbol"
diagnostics; toString() already does demangling on Windows hosts.
Also make lld::demangleMSVC() (called by toString(Symbol*)) call LLVM's
microsoftDemangle() instead of UnDecorateSymbolName() so that it works on
non-Windows hosts – this makes both updating tests easier and provides a better
user experience for people doing cross-links.
This doesn't yet do the right thing for symbols starting with __imp_, but that
can be improved in a follow-up.
Differential Revision: https://reviews.llvm.org/D52104
llvm-svn: 342332
MinGW uses these kind of list terminator symbols for traversing
the constructor/destructor lists. These list terminators are
actual pointers entries in the lists, with the values 0 and
(uintptr_t)-1 (instead of just symbols pointing to the start/end
of the list).
(This mechanism exists in both the mingw-w64 crt startup code and
in libgcc; normally the mingw-w64 one is used, but a DLL build of
libgcc uses the libgcc one. Therefore it's not trivial to change
the mechanism without lots of cross-project synchronization and
potentially invalidating some combinations of old/new versions
of them.)
When mingw-w64 has been used with lld so far, the CRT startup object
files have so far provided these symbols, ending up with different,
incompatible builds of the CRT startup object files depending on
whether binutils or lld are going to be used.
In order to avoid the need of different configuration of the CRT startup
object files depending on what linker to be used, provide these symbols
in lld instead. (Mingw-w64 checks at build time whether the linker
provides these symbols or not.) This unifies this particular detail
between the two linkers.
This does disallow the use of the very latest lld with older versions
of mingw-w64 (the configure check for the list was added recently;
earlier it simply checked whether the CRT was built with gcc or clang),
and requires rebuilding the mingw-w64 CRT. But the number of users of
lld+mingw still is low enough that such a change should be tolerable,
and unifies this aspect of the toolchains, easing interoperability
between the toolchains for the future.
The actual test for this feature is added in ctors_dtors_priority.s,
but a number of other tests that checked absolute output addresses
are updated.
Differential Revision: https://reviews.llvm.org/D52053
llvm-svn: 342294
-z interpose sets the DF_1_INTERPOSE flag, marking the object as an
interposer.
Via FreeBSD PR 230604, linking Valgrind with lld failed.
Differential Revision: https://reviews.llvm.org/D52094
llvm-svn: 342239
The PE spec says that they will be separated by spaces, but link.exe
handles it just fine if they are separated by null bytes as well.
This adds tests to the lld repo, with the actual functional change
in LLVM in SVN r342204.
Differential Revision: https://reviews.llvm.org/D52014
llvm-svn: 342206
Patch by Thomas Roughton.
This patch adds support for linking with multiple definitions to LLD's
COFF driver, in line with link.exe's /force:multiple option.
Differential Revision: https://reviews.llvm.org/D50598
llvm-svn: 342191
For lld-link missing.obj, lld-link currently prints:
lld-link: error: could not open foo.obj: No such file or directory
lld-link: warning: /machine is not specified. x64 is assumed
lld-link: error: subsystem must be defined
The 2nd and 3rd diagnostics are consequences of the input not existing and are
not interesting. If input files are missing, the best thing we can do is point
that out and then return.
Differential Revision: https://reviews.llvm.org/D51981
llvm-svn: 342158
If --just-syms is used the mapping symbols from the ELF file will be
absolute symbols with no section. The code to process mapping symbols in
--fix-cortex-a53-843419 assumes that these symbols have a defining section
so a crash will result when --just-syms is used. The simple fix is to not
process the symbol when it doesn't have a section.
Fixes PR37971
Differential Revision: https://reviews.llvm.org/D52038
llvm-svn: 342146
Shoaib Meenai