Currently LLVM's paralellForEach has a problem with reentracy.
That caused https://bugs.llvm.org/show_bug.cgi?id=35788 (lld somtimes
hangs while linking Ruby 2.4) because maybeCompress calls writeTo which
uses paralellForEach.
This patch is to avoid using paralellForEach to call maybeCompress
to workaround the issue.
llvm-svn: 322041
These tests started failing because we now properly convert
DefRange records to and from Yaml, but there were some old yaml
files that had incorrect record definitions generated by the
old buggy obj2yaml. Rather than try to re-generate the yaml files,
it's easier to just remove the records, and they weren't necessary
for the proper execution of the test anyway.
llvm-svn: 322040
The body of the in scanRelocs is fairly big. This moves it to its own
function.
It is not a big readability win by itself, but should help further
refactoring.
llvm-svn: 322035
The problem was that our Obj -> Yaml dumper had not been taught
to handle certain types of records. This meant that when I
generated the test input files, the records were still there but
none of its fields were filled out. So when it did the
Yaml -> Obj conversion as part of the test, it generated records
with garbage in them.
The patch here fixes the Obj <-> Yaml converter, and additionally
updates the test file with fresh Yaml generated by the fixed
converter.
llvm-svn: 322029
It was being set but never used, and its value is only ever needed
locally in lld::coff::link.
Differential Revision: https://reviews.llvm.org/D41814
llvm-svn: 322026
Previously, in r320472, I moved the calculation of section offsets and sizes
for compressed debug sections into maybeCompress, which happens before
assignAddresses, so that the compression had the required information. However,
I failed to take account of relocations that patch such sections. This had two
effects:
1. A race condition existed when a debug section referred to a different debug
section (see PR35788).
2. References to symbols in non-debug sections would be patched incorrectly.
This is because the addresses of such symbols are not calculated until after
assignAddresses (this was a partial regression caused by r320472, but they
could still have been broken before, in the event that a custom layout was used
in a linker script).
assignAddresses does not need to know about the output section size of
non-allocatable sections, because they do not affect the value of Dot. This
means that there is no longer a reason not to support custom layout of
compressed debug sections, as far as I'm aware. These two points allow for
delaying when maybeCompress can be called, removing the need for the loop I
previously added to calculate the section size, and therefore the race
condition. Furthermore, by delaying, we fix the issues of relocations getting
incorrect symbol values, because they have now all been finalized.
llvm-svn: 321986
Previously, the COFF driver would call exit(1) from the
ErrorHandler in the case of a link error, even if
CanExitEarly=false was specified. Now it initializes
the ErrorHandler in the same way that the ELF driver does.
Patch by Andrew Kelley.
Differential Revision: https://reviews.llvm.org/D41803
llvm-svn: 321983
LLD previously used to handle dynamic lists and version scripts in the
exact same way, even though they have very different semantics for
shared libraries and subtly different semantics for executables. r315114
untangled their semantics for executables (building on previous work to
correct their semantics for shared libraries). With that change, dynamic
lists won't set the default version to VER_NDX_LOCAL, and so resetting
the version to VER_NDX_GLOBAL in scanShlibUndefined is unnecessary.
This was causing an issue because version scripts containing `local: *`
work by setting the default version to VER_NDX_LOCAL, but scanShlibUndefined
would override this default, and therefore symbols which should have
been local would end up in the dynamic symbol table, which differs from
both bfd and gold's behavior. gold silently keeps the symbol hidden in
such a scenario, whereas bfd issues an error. I prefer bfd's behavior
and plan to implement that in LLD in a follow-up (and the test case
added here will be updated accordingly).
Differential Revision: https://reviews.llvm.org/D41639
llvm-svn: 321982
This is not a record type that clang currently generates,
but it is a record that is encountered in object files generated
by cl. This record is unusual in that it refers directly to
the string table instead of indirectly to the string table via
the FileChecksums table. Because of this, it was previously
overlooked and we weren't remapping the string indices at all.
This would lead to crashes in MSVC when trying to display a
variable whose debug info involved an S_FILESTATIC.
Original bug report by Alexander Ganea
Differential Revision: https://reviews.llvm.org/D41718
llvm-svn: 321883
We normally want to ignore SHT_NOBITS sections when computing
offsets. The sh_offset of section itself seems to be irrelevant and
- If the section is in the middle of a PT_LOAD, it will make no
difference on the computed offset of the followup section.
- If it is in the end of a PT_LOAD, we want to avoid its alignment
changing the offset of the followup sections.
The issue is if it is at the start of the PT_LOAD. In that case we do
have to align it so that the following sections have congruent address
and offset module the page size. We were not handling this case.
This should fix freebsd kernel link.
llvm-svn: 321657
This is "Bug 35751 - .dynamic relocation entries omitted if output
contains only IFUNC relocations"
We have InX::RelaPlt and InX::RelaIPlt synthetic sections for PLT relocations.
They are usually live in rela.plt section. Problem appears when InX::RelaPlt
section is empty. In that case we did not produce normal set of dynamic tags
required, because logic was written in the way assuming we always have
non-IRelative relocations in rela.plt.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D41592
llvm-svn: 321600
This was raised in comments for D41592.
With current code we always assign parent
section for Rel[a] sections like
InX::RelaPlt or InX::RelaDyn, so checking
their parent for null is excessive.
llvm-svn: 321581
If using a version script with a `local: *` in it, symbols in shared
libraries will still get default visibility if another shared library on
the link line has an undefined reference to the symbol. This is quite
surprising. Neither bfd nor gold have this behavior when linking a
shared library, and none of LLD's tests fail without this behavior, so
it seems safe to limit scanShlibUndefined to executables.
As far as executables are concerned, gold doesn't do any automatic
default visibility marking, and bfd issues a link error about a shared
library having a reference to a hidden symbol rather than silently
giving that symbol default visibility. I think bfd's behavior here is
preferable to LLD's, but that's something to be considered in a
follow-up.
Differential Revision: https://reviews.llvm.org/D41524
llvm-svn: 321578
Summary:
lld-link accepts link.exe's /ignore option, but used to ignore
it. This can lead to semantic differences when warnings are treated as
fatal errors. One such case is when we resolve an __imp_ symbol to a
local definition. We emit a warning in that case, which /wx turns into
a fatal. This change makes lld-link accept /ignore:4217 to suppress
that warning, so that code that links with link.exe /wx /ignore:4217
links with lld-link, too.
Fixes PR35762.
Reviewers: rnk, ruiu
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41606
llvm-svn: 321512
This makes adjustExpr a bit simpler too IMHO.
It seems that some of the complication around relocation processing
is that we are trying to create copy relocations too early. It seems
we could handle a few simple cases first and continue.
llvm-svn: 321507
Previously we failed to resolve them when produced executables:
"relocation R_X86_64_32 cannot be used against shared object; recompile with -fPIC"
Patch fixes it so that we resolve them to 0 for executables.
And for -shared case we still should produce the relocation.
This finishes fixing PR35720.
DIfferential revision: https://reviews.llvm.org/D41551
llvm-svn: 321473
This is an aesthetic change to represent a placeholder for later
binary patching as "0, 0, 0, 0" instead of "0x00, 0x00, 0x00, 0x00".
The former is how we represent it in COFF, and I found it easier to
read than the latter.
llvm-svn: 321471
Patch by Takuto Ikuta.
This patch reduces link time of chromium's blink_core.dll in component
build. Total size of input argument in .directives become nearly 300MB
in the build and no rsp file is used. Speedup link by skipping duplicate
parsing.
On my desktop machine, 4 times stats are like below. Improved around 15%.
This patch
TotalSeconds : 18.408538
TotalSeconds : 17.2996744
TotalSeconds : 17.1053862
TotalSeconds : 17.809777
avg: 17.6558439
master
TotalSeconds : 20.9290504
TotalSeconds : 19.9158213
TotalSeconds : 21.0643515
TotalSeconds : 20.8775831
avg: 20.696701575
Differential Revision: https://reviews.llvm.org/D41581
llvm-svn: 321470
If a relocation cannot be implemented by the dynamic linker and the
section is rw, allow creating a plt entry to use as the function
address as if the section was ro.
This matches bfd and gold. It also matches our behavior with -z
notext.
llvm-svn: 321430
Advance the memory region offset when handling a linker script data
command such as BYTE or LONG. Failure to advance the offset results
in corrupted output with overlapping sections.
Update tests to check for this combination of both a) memory regions
and b) data commands.
Fixes https://bugs.llvm.org/show_bug.cgi?id=35565
Patch by Owen Shaw!
llvm-svn: 321418
We normally avoid "switch (Config->EKind)", but in this case I think
it is worth it.
It is only executed when there is an error and it allows detemplating
a lot of code.
llvm-svn: 321404
This is part of PR35720.
Currently LLD allows dynamic relocations against text when -z notext is given.
Though for non-PIC relocations like R_X86_64_PC32 that does not work,
we produce "relocation R_X86_64_PC32 cannot be used against shared object;"
error because they may overflow in runtime.
Solution implemented is to use PLT for them.
Differential revision: https://reviews.llvm.org/D41541
llvm-svn: 321400
When two linker script symbols are subtracted, the result should be absolute.
This is the behavior of binutils' ld.
Patch by Erick Reyes!
llvm-svn: 321390
Summary:
Currently the test only checks behaviour for weak function symbols.
Should be good to merge straight away?
Reviewers: sbc100
Reviewed By: sbc100
Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D41449
llvm-svn: 321308
In this case we are calling a function pointer which
a type that doesn't otherwise exist in the code.
Clearly this code can't would trap if it was ever
called (because there is not such function that
the pointer can resolve to).
But it should valid and compile and link and validation
time.
llvm-svn: 321134
Store data relocations with their respective segment.
This allows relocations to be applied as each segment
is written (and therefore in parallel).
Differential Revision: https://reviews.llvm.org/D41410
llvm-svn: 321105
This change add support for init functions in the linking
section, but only in -r/--relocatable mode.
Differential Revision: https://reviews.llvm.org/D41375
llvm-svn: 321088
A more efficient PLT sequence can be used when the distance between the
.plt and the end of the .plt.got is less than 128 Megabytes, which is
frequently true. We fall back to the old sequence when the offset is larger
than 128 Megabytes. This gives us an alternative to forcing the longer
entries with --long-plt as we gracefully fall back to it as needed.
See ELF for the ARM Architecture Appendix A for details of the PLT sequence.
Differential Revision: https://reviews.llvm.org/D41246
llvm-svn: 320987
This is a preparetory change for function gc which also
requires relocations to be copied in ranges like this.
Differential Revision: https://reviews.llvm.org/D41313
llvm-svn: 320948
Summary:
1. Use stream 0 only for combined module. Previously if combined module was not
processes ThinLTO used the stream for own output. However small changes in input,
could trigger combined module and shuffle outputs making life of llvm::LTO harder.
2. Always process combined module and write output to stream 0. Processing empty
combined module is cheap and allows llvm::LTO users to avoid implementing processing
which is already done in llvm::LTO.
Subscribers: mehdi_amini, inglorion, eraman, hiraditya
Differential Revision: https://reviews.llvm.org/D41267
llvm-svn: 320905
/debug and /debug:dwarf are orthogonal. An object file can contain both
CodeView and DWARF debug info, so the combination of /debug:dwarf and
/debug should generate both DWARF and a PDB, rather than /debug:dwarf
always suppressing PDB creation.
/nopdb is now redundant and can be removed. /debug /nopdb was previously
used to support DWARF, but specifying /debug:dwarf is entirely
equivalent to that combination now.
Differential Revision: https://reviews.llvm.org/D41310
llvm-svn: 320896
We can just pass multiple options to hasArgs (which will check for any
of those options being present) instead of calling it multiple times.
llvm-svn: 320892
The COFF linker automatically sets the IMAGE_DLL_CHARACTERISTICS_NO_SEH
when suitable, similarly to link.exe.
Differential Revision: https://reviews.llvm.org/D41275
llvm-svn: 320861
We add dynamic section entries both in the ctor of the class and
DynamicSection::finalizeContents(). Some entries need to be added early
in the ctor because they add strings to .dynstr. Other entries were
intended to be added in finalizeContents(). However, some entries are
added in the ctor even though they don't add strings. This patch
fix the issue.
llvm-svn: 320851
Since imports are undefined symbols we know we can
find all of them my looking at the symbol table alone.
(i.e. imports cannot be have local binding).
This will be strictly faster and also allows us
to to remove a method from Symbol class
Differential Revision: https://reviews.llvm.org/D41304
llvm-svn: 320847
We only need to exceed 128 Megabytes to provoke the generation of a range
extension thunk. This brings the file size down to just over 128 Megabytes.
llvm-svn: 320821
I noticed that the continue this patch deletes was not tested. Trying
to add a test I realized that we never put a VER_NDX_LOCAL symbol in
the dynamic symbol table. There doesn't seem to be any reason for a
linker to use VER_NDX_LOCAL for a defined shared symbol.
llvm-svn: 320817
The ARM.exidx section contains a table of 8-byte entries with the first
word of each entry an offset to the function it describes and the second
word instructions for unwinding if an exception is thrown from that
function. The SHF_LINK_ORDER processing will order the table in ascending
order of the functions described by the exception table entries. As the
address range of an exception table entry is terminated by the next table
entry, it is possible to merge consecutive table entries that have
identical unwind instructions.
For this implementation we define a table entry to be identical if:
- Both entries are the special EXIDX_CANTUNWIND.
- Both entries have the same inline unwind instructions.
We do not attempt to establish if table entries that are references to
.ARM.extab sections are identical.
This implementation works at a granularity of a single .ARM.exidx
InputSection. If all entries in the InputSection are identical to the
previous table entry we can remove the InputSection. A more sophisticated
but more complex implementation would rewrite InputSection contents so that
duplicates within a .ARM.exidx InputSection can be merged.
Differential Revision: https://reviews.llvm.org/D40967
llvm-svn: 320803
This patch provides the mechanism to fix instances of the instruction
sequence that may trigger the cortex-a53 843419 erratum. The fix is
provided by an alternative instruction sequence to remove one of the
erratum conditions. To reach this alternative instruction sequence we
replace the original instruction with a branch to the alternative
sequence. The alternative sequence is responsible for branching back to
the original.
As there is only erratum to fix the implementation is specific to
AArch64 and the specific erratum conditions. It should be generalizable
to other targets and erratum if needed.
Differential Revision: https://reviews.llvm.org/D36749
llvm-svn: 320800
Windows paths have colons in them, so the regex will fail there. Just
match for any character; the rest of the message will restrict the match
to the path anyway.
llvm-svn: 320793
Locally imported symbols are a very surprising linker feature. link.exe
warns for them, and we should warn too.
Differential Revision: https://reviews.llvm.org/D41269
llvm-svn: 320792
Specifically, libwidevinecdm.so in Chrome has such bad symbol.
It seems the BFD linker handles them as local symbols, so instead
of inserting them to the symbol table, we should skip them too.
Differential Revision: https://reviews.llvm.org/D41257
llvm-svn: 320770
This adds the /DEBUG:GHASH option to LLD which will look for
the existence of .debug$H sections in linker inputs and use them
to accelerate type merging. The clang-cl side has already been
added, so this completes the work necessary to begin experimenting
with this feature.
Differential Revision: https://reviews.llvm.org/D40980
llvm-svn: 320719
This is similar to what was added in SVN r277838 for 24 bit
branch instructions.
Differential Revision: https://reviews.llvm.org/D41163
llvm-svn: 320677
This works for linking the output from the MSVC compiler.
The pdata entries for arm64 seem to be 8 bytes in the same
(or at least similar) form to arm.
Differential Revision: https://reviews.llvm.org/D41160
llvm-svn: 320676
We might crash in 'ARMExidxSentinelSection::writeTo()' because it expected
the sentinel entry to be put in the same 'InputSectionDescription' as
the last real entry. This assumption fails if the last output section command
for .ARM.exidx is anything but an input section description, because in this
case 'OutputSection::addSection()' creates a new 'InputSectionDescription'.
Differential Revision: https://reviews.llvm.org/D41105
llvm-svn: 320668
It is currently in InputSectionBase. Only InputSections are used in
ICF, so Repl should be move to InputSection to clear the class
hierarchy or, like this patch does, to SectionBase for convenience.
The convenience of having it on the base class is that we can just
access the replacement without having to first check if it is an
InputSection. It is a bit less code and a bit faster as some of this
code is very hot.
I got up to 1.77% improvement in clang-gdb-index and no regressions
according to lnt.
llvm-svn: 320654
Without this the LLVM_BUILD_LLVM_DYLIB+DLLVM_LINK_LLVM_DYLIB build
break.
Also remove unneeded lldCore from wasm/CMakeLists.txt
Differential Revision: https://reviews.llvm.org/D41194
llvm-svn: 320610
Having a SectionBase method check Repl is inconsistent with how we
handle other section information.
For example, if a section is replaced, Sec->Live is false and it is
natural for Sec->getOutputSection() to be null.
It is the symbol that is moved to the replacement section.
llvm-svn: 320599
The linker refuses using -dynamicbase:no on these architectures.
Stop passing -dynamicbase (which just reinforces the lld-link
default) for simplicity.
Differential Revision: https://reviews.llvm.org/D41052
llvm-svn: 320518
Moving the SHF_LINK_ORDER processing out of OutputSection::finalize()
means that we no longer need to copy all InputSections as we now only need
the first one.
Differential Revision: https://reviews.llvm.org/D40966
llvm-svn: 320478
By moving this step before thunk creation and other processing that depends
on the size of sections, we permit removal of duplicates in the .ARM.exidx
section.
Differential Revision: https://reviews.llvm.org/D40964
llvm-svn: 320477
The size of an OutputSection is calculated early, to aid handling of compressed
debug sections. However, subsequent to this point, unused synthetic sections are
removed. In the event that an OutputSection, from which such an InputSection is
removed, is still required (e.g. because it has a symbol assignment), and no longer
has any InputSections, dot assignments, or BYTE()-family directives, the size
member is never updated when processing the commands. If the removed InputSection
had a non-zero size (such as a .got.plt section), the section ends up with the
wrong size in the output.
The fix is to reset the OutputSection size prior to processing the linker script
commands relating to that OutputSection. This ensures that the size is correct even
in the above situation.
Additionally, to reduce the risk of developers misusing OutputSection Size and
InputSection OutSecOff, they are set to simply the number of InputSections in an
OutputSection, and the corresponding index respectively. We cannot completely
stop using them, due to SHF_LINK_ORDER sections requiring them.
Compressed debug sections also require the full size. This is now calculated in
maybeCompress for these kinds of sections.
Reviewers: ruiu, rafael
Differential Revision: https://reviews.llvm.org/D38361
llvm-svn: 320472
By using an index instead of a pointer for verdef we can put the index
next to the alignment field. This uses the otherwise wasted area and
reduces the shared symbol size.
By itself the performance change of this is in the noise, but I have a
followup patch to remove another 8 bytes that improves performance
when combined with this.
llvm-svn: 320449
An internal linker has support for merging identical data and in some
cases it can be a significant win.
This is behind an off by default flag so it has to be requested
explicitly.
llvm-svn: 320448
Also make function bodies unique so they can be distinguished
in the output. This is helpful for adding support for --gc-sections.
Differential Revision: https://reviews.llvm.org/D41093
llvm-svn: 320441
When an output section has no byte commands and has no input sections then it
would be ideal if the type of the section is SHT_NOBITS so that the file can
take up less space. This change sets the default type of of output sections to
SHT_NOBITS instead of SHT_PROGBITS to allow this. This required some minor test
changes (which double as tests for this new behavior) but extend-pt-load.s had
be changed in a non-trivial way. Since it seems to me that the point of the
test is to point out the consequences of how flags are assigned to output
sections that don't have input sections I changed the test to work and still
show how the memsize of the executable segment was changed.
Differential Revision: https://reviews.llvm.org/D41082
llvm-svn: 320437
In the following command line,
lld-link foo/bar.lib /defaultlib:bar.lib
"/defaultlib:bar.lib" should be a nop even if a file with the same
name exists in other library search path.
Fixes https://bugs.llvm.org/show_bug.cgi?id=35476
Differential Revision: https://reviews.llvm.org/D41094
llvm-svn: 320434
Shoaib Meenai