Previously we handled this option implicitly, only
for infering unresolved symbols handling policy.
ld man says: "--noinhibit-exec Retain the executable
output file whenever it is still usable",
and we may want to handle other cases too.
Differential revision: https://reviews.llvm.org/D35793
llvm-svn: 309091
Summary:
If the linker is invoked with `--chroot /foo` and `/bar/baz.o`, it
tries to read the file from `/foo/bar/baz.o`. This feature is useful
when you are dealing with files created by the --reproduce option.
Reviewers: grimar
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D35517
llvm-svn: 308646
This is PR33766.
-F name
--filter=name
When creating an ELF shared object, set the internal DT_FILTER field to the specified name. This tells the dynamic linker that the symbol table of the shared object which is being created should be used as a filter on the symbol table of the shared object name.
If you later link a program against this filter object, then, when you run the program, the dynamic linker will see the DT_FILTER field. The dynamic linker will resolve symbols according to the symbol table of the filter object as usual, but it will actually link to the definitions found in the shared object name. Thus the filter object can be used to select a subset of the symbols provided by the object name.
(https://linux.die.net/man/1/ld).
Shared Objects as Filters:
https://docs.oracle.com/cd/E19683-01/817-3677/chapter4-31738/index.html
Differential revision: https://reviews.llvm.org/D35352
llvm-svn: 308167
Previously, when symbol A is renamed B, both A and B end up having
the same name. This is because name is a symbol's attribute, and
we memcpy symbols for symbol renaming.
This pathc saves the original symbol name and restore it after memcpy
to keep the original name.
This patch shouldn't change program's meaning, but names in symbol
tables make more sense than before.
llvm-svn: 306036
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
llvm-svn: 304864
procedural optimizations to prevent dropping symbols and allow the linker
to process re-directs.
PR33145: --wrap doesn't work with lto.
Differential Revision: https://reviews.llvm.org/D33621
llvm-svn: 304719
The .dynamic section of an ELF almost doesn't need to be written to with
the exception of the DT_DEBUG entry. For several reasons having a read
only .dynamic section would be useful. This change adds the -z keyword
"rodynamic" which forces .dynamic to be read-only. In this case DT_DEBUG
will not be emited.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D33251
llvm-svn: 304024
This reverts changes introduced in r302414 "[ELF] - Set DF_STATIC_TLS flag for i386 target."
Because DF_STATIC_TLS does not look to be used by glibc or anything else.
llvm-svn: 302884
This is PR32437.
DF_STATIC_TLS
If set in a shared object or executable, this flag instructs the
dynamic linker to reject attempts to load this file dynamically.
It indicates that the shared object or executable contains code
using a static thread-local storage scheme. Implementations need
not support any form of thread-local storage.
Patch checks if IE/LE relocations were used to check if code uses
static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D32354
llvm-svn: 302414
It seems virtually everyone who tries to do LTO build with Clang and
LLD was hit by a mistake to forget using llvm-ar command to create
archive files. I wasn't an exception. Since this is an annoying common
issue, it is probably better to handle that gracefully rather than
reporting an error and tell the user to redo build with different
configuration.
Differential Revision: https://reviews.llvm.org/D32721
llvm-svn: 302083
For an option -foo-bar-baz, we have Config->FooBarBaz. Since -rpath is
-rpath and not -r-path, it should be Config->Rpath instead Config->RPath.
llvm-svn: 301759
Patch implements --compress-debug-sections=zlib.
In compare with D20211 (a year old patch, abandoned), it implementation
uses streaming and fully reimplemented, does not support zlib-gnu for
simplification.
This is PR32308.
Differential revision: https://reviews.llvm.org/D31941
llvm-svn: 300444
This is a shorthand for Config->Wordsize == 8. So this is not strictly
necessary but seems handy. "Is 64 bit?" is easier to read than "Is
wordsize 8 byte?"
llvm-svn: 298463
We had a few Config member functions that returns configuration values.
For example, we had is64() which returns true if the target is 64-bit.
The return values of these functions are constant and never change.
This patch is to compute them only once to make it clear that they'll
never change.
llvm-svn: 298168
Summary:
When we perform LTO builds with a version of ar that does not
understand LLVM bitcode objects, we end up with undefined references,
because our archive files do not list the bitcode symbols in their
indices. The error messages do not make it clear what the real problem
is. This change adds a note that points out the likely problem and
solution. It is similar in spirit to r282633, but aims to avoid false
positives by only triggering when we see both undefined references and
archives without symbols in their indices.
Fixes PR32281.
Reviewers: davide, ruiu, tejohnson
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31011
llvm-svn: 298124
This patch causes us to use pruneCache() to prune the ThinLTO cache after
completing LTO. A new flag --thinlto-cache-policy allows users to configure
the policy.
Differential Revision: https://reviews.llvm.org/D31021
llvm-svn: 298036
Patch introduces Config->is64Bit() and with help of that detemplates
GotPltSection and IgotPltSection sections
Differential revision: https://reviews.llvm.org/D30944
llvm-svn: 297813
gold linker manual describes them as:
-z text Do not permit relocations in read-only segments
-z notext Permit relocations in read-only segments (default)
In LLD default is to not permit them. Patch implements -z notext.
Differential revision: https://reviews.llvm.org/D30530
llvm-svn: 297366
This patch adds an option named --thinlto-cache-dir, which specifies the
path to a directory in which to cache native object files for ThinLTO
incremental builds.
Differential Revision: https://reviews.llvm.org/D30509
llvm-svn: 296702
with temporarily file name fix in testcase.
Original commit message:
-q, --emit-relocs - Generate relocations in output
Simplest implementation:
* no GC case,
* no "/DISCARD/" linkerscript command support.
This patch is extracted from D28612 / D29636,
Relative to PR31579.
Differential revision: https://reviews.llvm.org/D29663
llvm-svn: 294469
-q, --emit-relocs - Generate relocations in output
Simplest implementation:
* no GC case,
* no "/DISCARD/" linkerscript command support.
This patch is extracted from D28612 / D29636,
Relative to PR31579.
Differential revision: https://reviews.llvm.org/D29663
llvm-svn: 294464
Now reportUndefined only has to look at Config->UnresolvedSymbols and
the symbol. getUnresolvedSymbolOption does all the hard work of
mapping options like -shared and -z defs to one of the
UnresolvedPolicy enum entries.
The critical fix is that now "-z defs --warn-unresolved-symbols" only
warns.
llvm-svn: 293290
It now uses the same infrastructure as symbol versions. This fixes us
creating a dynamic relocation without a corresponding dynamic symbol.
This also means that unlike gold and bfd we keep a STB_LOCAL in the
static symbol table. It seems an odd feature to offer precise control
over what is in a symbol table that is not used by the dynamic
linker. We can bring this back if needed, but it would probably be
better to just have --discard option that tells the linker to keep in
the static symbol table only what is in the dynamic one.
Should fix the eog build.
llvm-svn: 293093
Currently ld.lld -r allocates space for common symbols, whereas ld.bfd
-r doesn't. As a result the OpenBSD makefile bits for creating libraries
fail as they use ld -X -r to strip local symbols, which results in
duplicate symbol errors because space for the common symbols has been
allocated.
The diff also implements the --define-commons option such that allocation
of commons can be forced even if -r is used.
Patch by Mark Kettenis.
llvm-svn: 292878
That variable was of type DenseMap<StringRef, unsigned>, but the
unsigned numbers needed to be monotonicly increasing numbers because
the implementation that used the variable depended on that fact.
That was an implementation detail and shouldn't have leaked into Config.
This patch simplifies its type to std::vector<StringRef>.
llvm-svn: 290151
--retain-symbols-file=filename
Retain only the symbols listed in the file filename, discarding all others.
filename is simply a flat file, with one symbol name per line. This option
is especially useful in environments (such as VxWorks) where a large global
symbol table is accumulated gradually, to conserve run-time memory.
Note: though documentation says "--retain-symbols-file does not discard
undefined symbols, or symbols needed for relocations.", both bfd and gold
do that, and this patch too, like testcase show.
Differential revision: https://reviews.llvm.org/D27716
llvm-svn: 290122
Use of CachedHashStringRef makes sense only when we reuse hash values.
Sprinkling it to all DenseMap has no benefits and just complicates data types.
Basically we shouldn't use CachedHashStringRef unless there is a strong
reason to to do so.
llvm-svn: 290076
The feature is documented as
-----------------------------
The format of the dynamic list is the same as the version node
without scope and node name. See *note VERSION:: for more
information.
--------------------------------
And indeed qt uses a dynamic list with an 'extern "C++"' in it. With
this patch we support that
The change to gc-sections-shared makes us match bfd. Just because we
kept bar doesn't mean it has to be in the dynamic symbol table.
The changes to invalid-dynamic-list.test and reproduce.s are because
of the new parser.
The changes to version-script.s are the only case where we change
behavior with regards to bfd, but I would like to see a mix of
--version-script and --dynamic-list used in the wild before
complicating the code.
llvm-svn: 289082
George Rimar