This is a safeguard against data loss if the user specifies a directory
that is not a cache directory. Teach the existing cache pruning clients
to create files with appropriate names.
Differential Revision: https://reviews.llvm.org/D31109
llvm-svn: 298271
__start_xxx symbol keeps section xxx alive only if it is not
SHF_LINK_ORDER. Such sections can be used for user metadata, when
__start_xxx is used to iterate over section contents at runtime, and
the liveness is determined solely by the linked (associated) section.
This was earlier implemented in r294592, and broken in r296723.
Differential Revision: https://reviews.llvm.org/D30964
llvm-svn: 298154
Do not take in account the `Live` flag while collecting .reginfo, .MIPS.options,
and .MIPS.abiflags input sections to produce corresponding output sections.
These sections have information purpose and should be always produced per
ABI requirements.
llvm-svn: 298093
This fixes pr32031 by representing the expressions results as a
SectionBase and offset. This allows us to use an input section
directly instead of getting lost trying to compute an offset in an
outputsection when not all the information is available yet.
This also creates a struct to represent the *value* of and expression,
allowing the expression itself to be a simple typedef. I think this is
easier to read and will make it easier to extend the expression
computation to handle more complicated cases.
llvm-svn: 298079
It failed for me under windows,
touch reported invalid date format.
Seems related to 12h/24h format, though
I don't understant why 197001010200 does not work,
but 197001010300 works, I see no logic here.
Changed to 197001011200.
llvm-svn: 298064
Was fixed, details on review page.
Original commit message:
That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.
This is splitted from D30541 and polished.
Difference from D30541 that all logic of SharedSymbol
converting to DefinedRegular was removed for now and
probably will be posted as separate patch.
Differential revision: https://reviews.llvm.org/D30892
llvm-svn: 298062
Patch to fix lld tests after my llvm-objdump patch to fix branch labels for
Thumb targets.
Reviewed by: emaste
Differential Revision: https://reviews.llvm.org/D30986
llvm-svn: 298055
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
The MSVC linker doesn't like archive files containing non-native object
files.
When we are doing an LTO build, we may create archive files containing
both LLVM bitcode files and native object files. For example, if a
project contains assembly files and C++ files, we create native object
files for the assembly files and LLVM bitcode files for the C++ files.
With the /msvclto option, LLD passes archive files to the MSVC linker.
Previously, we didn't pass archive files if they contain at least one
bitcode files. That wasn't correct because the native object files that
weren't passed to the MSVC linker may be needed to complete linking.
In this patch, we create new temporary archive files to strip bitcode
files.
Differential Revision: https://reviews.llvm.org/D31053
llvm-svn: 297997
This test would have been broken if we convert SharedSymbols
to DefinerRegular without saving the symbol version information when
creating .bss/.bss.rel.ro sections for copy relocations.
Relative to D30541, PR32167
llvm-svn: 297948
D30229 changes the defaults based on section names to match the
GAS behavior, which breaks some of the tests that rely on the old
defaults.
Differential Revision: https://reviews.llvm.org/D30967
llvm-svn: 297803
This also requires postponing the assignment the assignment of
symbols defined in input linker scripts since those can refer to
output sections and in case we don't have a SECTIONS command, we
need to wait until all output sections have been created and
assigned addresses.
Differential Revision: https://reviews.llvm.org/D30851
llvm-svn: 297802
Being passed -z notext is a pretty strong indication that the user is
OK with text relocations. This is not the same behavior as bfd, but
bfd defaults to -z notext, so it has to try to avoid text relocations
and use them as a last resort.
llvm-svn: 297789
lld crashes when .eh_frame or .eh_frame_hdr section is discarded
in linker script and there is no PHDRS directive.
Differential revision: https://reviews.llvm.org/D30885
llvm-svn: 297712
Synthetic sections don't belong to any input file, but still they
are input sections. Whenever problem occurs with relocations in
these sections lld crashes in error reporting, trying to print
input file name.
Differential revision: https://reviews.llvm.org/D30889
llvm-svn: 297711
Previously, it created a temporary directory and then failed when
FileOutputBuffer tried to rename that file to the destination file
(which is actually a directory name).
Differential Revision: https://reviews.llvm.org/D30912
llvm-svn: 297679
Patch from James Henderson.
If a user has a long link, e.g. due to a large LTO link, they do not
wish to run it and find that it failed because there was a mistake in
their command-line, after they waited for some significant amount of
time. This change adds some basic checking of the linker output file
path, which is run shortly after parsing the command-line and linker
script. An error is emitted if LLD cannot write to the specified path.
Differential Revision: https://reviews.llvm.org/D30449
llvm-svn: 297645
Fix a bug introduced in r297313 which caused them to resolve to the end
of the ELF header in PIEs and DSOs.
Differential Revision: https://reviews.llvm.org/D30843
llvm-svn: 297638
Options can start with `-` or `--` unless they start with "o".
Any option that starts with `-o` should be interpreted as an output
file name. This is a quote from the GNU ld man page.
Note -- there is one exception to this rule. Multiple letter
options that start with a lower case 'o' can only be preceded by
two dashes. This is to reduce confusion with the -o option.
So for example -omagic sets the output file name to magic whereas
--omagic sets the NMAGIC flag on the output.
We didn't handle that properly before.
llvm-svn: 297508
Using .eh_frame input section pattern in linker script currently
causes a crash; this is because .eh_frame input sections require
special handling since they're all combined into a synthetic
section rather than regular output section.
Differential Revision: https://reviews.llvm.org/D30627
llvm-svn: 297501
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
.eh_frame_hdr is a header constructed for .eh_frame sections.
We do not proccess .eh_frame when doing relocatable output,
so should not try to create .eh_frame_hdr too.
Previous behavior without this patch is segfault.
Fixes PR32118.
Differential revision: https://reviews.llvm.org/D30566
llvm-svn: 297365
Previously, if you have foo=bar in a definition file, this assertion
could fire because when symbols are read from file they could be mangled.
It seems that due to historical reasons underscore mangling scheme is
really ad-hoc, and I cannot find a clean way to handle this. I had
to just de-mangle symbols to search again.
llvm-svn: 297357
Some archive files created during chromium build contains both BC
and native files. If that's the case, we want to pass the archive
file to link.exe. Otherwise, the MSVC linker would complain that
there's an unresolved symbol in a given set of files.
I cannot explain why link.exe doesn't complain about the presence
of bitcode files in this case, but it seems link.exe doesn't touch BC.
llvm-svn: 297229
If /msvclto is specified, we compile bitcode files and pass it to the
MSVC linker, stripping all bitcode files. We haven't stripped archive
files, because I was thinking that the MSVC linker wouldn't touch files
in archive files. When we pass an object file to link.exe, all symbols
have been resolved already, so link.exe shoulnd't need any of the files
in archives.
It turns out that even though link.exe doesn't need to do that, it
seems to try to read each file in all archives. And if there's a non-
COFF file in an archive, it exists with an error message. So we need
to remove archives from the command line too.
llvm-svn: 297191
This change fixes a bug in which the Mips LA25 Thunks are always assigned
to the same Output section as the caller and not the callee as expected.
Differential Revision: https://reviews.llvm.org/D30637
llvm-svn: 297135
This puts us at parity with bfd, which could already gc this case.
I noticed the sections not being gced when linking a modified freebsd
kernel. A section that was not gced and not mentioned in the linker
script would end up breaking the expected layout. Since fixing the gc
is relatively simple and an improvement, that seems better than trying
to hack the orphan placement code.
There are 173 input section in the entire link whose names are valid C
identifiers, so this is probably not too performance critical.
llvm-svn: 297049
We were not gcing any section whose name was a C identifier. Both gold
and bfd only keep those if they are used.
To avoid having to create the __start/__stop symbols early or doing
string lookups in resolvedReloc, this patch just looks for undefined
symbols __start/__stop to decide if a section is needed or not.
llvm-svn: 296723
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
Previously, LLD merged all read-only sections. So the following
program prints out "true" if -icf=all is specified.
static const int foo = 1;
static const int bar = 1;
int main() { printf("%s\n", &foo == &bar ? "true" : "false"); }
This is somewhat counter-intuitive, and it actually caused nasty issues.
One example is https://bugs.chromium.org/p/chromium/issues/detail?id=682773#c24.
This patch changes the way how it works. Now ICF merges only functions
(i.e. executable sections).
Differential Revision: https://reviews.llvm.org/D30365
llvm-svn: 296534
I do not fully understand why we had these values in the tests, but
the new value matches what ld.bfd and ld.gold set, so I guess that
was just a mistake.
Differential Revision: https://reviews.llvm.org/D30441
llvm-svn: 296505
This reverts commit r296378.
I am pretty sure this is incorrect. In particular, for just
.cfi_startproc
nop
.cfi_endproc
We now add an extra 4 zeros that neither bfd nor gold add.
llvm-svn: 296503
Peter Collingbourne