| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 348955
|
|
|
|
|
|
|
|
|
|
|
| |
This is a part of https://bugs.llvm.org/show_bug.cgi?id=39810.
Seems it turns out that supporting /DISCARD/ for the .dynamic section with the
linker script is something we can do easily. The patch does this.
Differential revision: https://reviews.llvm.org/D55211
llvm-svn: 348749
|
|
|
|
|
|
|
|
|
| |
This is a part of https://bugs.llvm.org/show_bug.cgi?id=39810.
The patch allows discarding the .dynsym section using linker script.
Differential revision: https://reviews.llvm.org/D55218
llvm-svn: 348748
|
|
|
|
|
|
|
|
|
| |
This is a part of https://bugs.llvm.org/show_bug.cgi?id=39810.
The patch allows discarding the .dynstr section using linker script.
Differential revision: https://reviews.llvm.org/D55215
llvm-svn: 348746
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds support for the 'event section' specified in the exception
handling proposal.
Wasm exception handling binary model spec:
https://github.com/WebAssembly/exception-handling/blob/master/proposals/Exceptions.md#changes-to-the-binary-model
Reviewers: sbc100, ruiu
Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D54875
llvm-svn: 348703
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- LLVM style does not indent inside namespaces
- Alphabetize
Reviewers: ruiu
Subscribers: sbc100, llvm-commits
Differential Revision: https://reviews.llvm.org/D55406
llvm-svn: 348652
|
|
|
|
|
|
|
|
|
|
| |
Unlike GNU tar and libarchive bsdtar, NetBSD 'tar -t' output does not
use C-style escapes and instead outputs paths literally. Fix the test
to account both for escaped and literal backslash output.
Differential Revision: https://reviews.llvm.org/D55441
llvm-svn: 348628
|
|
|
|
|
|
|
| |
Mark tests requiring 'touch' to set atime unsupported on NetBSD
due to kernel limitation preventing it from working with noatime.
llvm-svn: 348607
|
|
|
|
| |
llvm-svn: 348505
|
|
|
|
|
|
| |
This addresses the missed review comment.
llvm-svn: 348480
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
section declarations.
This was a missing piece.
We started to print LMAs and information about assignments,
but did not do that for assignments outside of section declarations yet.
The patch implements it.
Differential revision: https://reviews.llvm.org/D45314
llvm-svn: 348468
|
|
|
|
|
|
|
|
| |
The test breaks on buildbots that don't enable the x86 backend. Other
tests in this directory explicitly require x86, so this should do the
trick.
llvm-svn: 348466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a part of
https://bugs.llvm.org/show_bug.cgi?id=39885
Linker script specification says:
"You can specify a file name to include sections from a particular file. You would
do this if one or more of your files contain special data that needs to be at a
particular location in memory."
LLD did not accept this syntax. The patch implements it.
Differential revision: https://reviews.llvm.org/D55324
llvm-svn: 348463
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we have a hash table containing strings and their offsets
to manage mergeable strings. Technically we can live without that, because
we can do binary search on a vector of mergeable strings to find a mergeable
strings.
We did have both the hash table and the binary search because we thought
that that is faster.
We recently observed that lld tend to consume more memory than gold when
building an output with debug info. A few percent of memory is consumed by
the hash table. So, we needed to reevaluate whether or not having the extra
hash table is a good CPU/memory tradeoff. I run a few benchmarks with and
without the hash table.
I got a mixed result for the benchmark. We observed a regression for some
programs by removing the hash table (that's what we expected), but we also
observed that performance imrpovements for some programs. This is perhaps
due to reduced memory usage.
Differential Revision: https://reviews.llvm.org/D55234
llvm-svn: 348401
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: grimar, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D55248
llvm-svn: 348311
|
|
|
|
|
|
|
|
|
|
|
| |
Previously these were dropped. We now understand them sufficiently
well to start emitting them. From the debugger's perspective, this
now enables us to have debug info about typedefs (both global and
function-locally scoped)
Differential Revision: https://reviews.llvm.org/D55228
llvm-svn: 348306
|
|
|
|
| |
llvm-svn: 348294
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from Andrew Kelley.
For context, see https://bugs.llvm.org/show_bug.cgi?id=39862
The use case is embedded / OS programming where the kernel wants
access to its own debug info via mapped dwarf info. I have a proof of
concept of this working, using this linker script snippet:
.rodata : ALIGN(4K) {
*(.rodata)
__debug_info_start = .;
KEEP(*(.debug_info))
__debug_info_end = .;
__debug_abbrev_start = .;
KEEP(*(.debug_abbrev))
__debug_abbrev_end = .;
__debug_str_start = .;
KEEP(*(.debug_str))
__debug_str_end = .;
__debug_line_start = .;
KEEP(*(.debug_line))
__debug_line_end =
.;
__debug_ranges_start
= .;
KEEP(*(.debug_ranges))
__debug_ranges_end
= .;
}
Differential revision: https://reviews.llvm.org/D55276
llvm-svn: 348291
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When linking the linux kernel on ppc64le
ld.lld -EL -m elf64lppc -Bstatic --orphan-handling=warn --build-id -o
.tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive
built-in.a --no-whole-archive --start-group lib/lib.a --end-group
ld.lld: error: discarding .rela.plt section is not allowed
The linker script discards with the following matches
*(.glink .iplt .plt .rela* .comment)
Differential Revision: https://reviews.llvm.org/D54871
llvm-svn: 348258
|
|
|
|
|
|
|
|
|
|
| |
When linking the linux kernel on ppc64 and ppc
ld.lld: error: unrecognized reloc 11
11 is PPC_REL14 and PPC64_REL14
Differential revision: https://reviews.llvm.org/D54868
llvm-svn: 348255
|
|
|
|
|
|
|
|
|
| |
We shouldn't be setting setting a max size for a table that is
being imported.
Differential Revision: https://reviews.llvm.org/D55231
llvm-svn: 348204
|
|
|
|
|
|
|
|
|
| |
At least on Linux, if a file size given to FileOutputBuffer is greater
than 2^63, it fails with "Invalid argument" error, which is not a
user-friendly error message. With this patch, lld prints out "output
file too large" instead.
llvm-svn: 348153
|
|
|
|
|
|
|
|
| |
There is no need to check that In.DynSymTab != nullptr,
because `includeInDynsym` already checks for `!Config->HasDynSymTab`
and `HasDynSymTab` is the pre-condition for In.DynSymTab creation.
llvm-svn: 348143
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now LLD might build the broken/incomplete .gdb_index when some DWARF v5
sections (like .debug_rnglists and .debug_addr) are used.
Particularly, for the case above, we emit an empty address area.
A test case is provided and patch fixes the issue.
Differential revision: https://reviews.llvm.org/D55109
llvm-svn: 348119
|
|
|
|
| |
llvm-svn: 348013
|
|
|
|
|
|
|
|
| |
Initial patch by Will Wilson (@lantictac)
Differential Revision: https://reviews.llvm.org/D55074
llvm-svn: 348001
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We initialize .text section with 0xcc (INT3 instruction), so we need to
explicitly write data even if it is zero if it can be in a .text section.
If you specify /merge:.rdata=.text, .rdata (which contains .idata) is put
to .text, so we need to do this.
Fixes https://bugs.llvm.org/show_bug.cgi?id=39826
Differential Revision: https://reviews.llvm.org/D55098
llvm-svn: 348000
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D55043
llvm-svn: 347909
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The _GLOBAL_OFFSET_TABLE_ is a linker defined symbol that is placed at
some location relative to the .got, .got.plt or .toc section. On some
targets such as Arm the correctness of some code sequences using a
relocation to _GLOBAL_OFFSET_TABLE_ depend on the value of the symbol
being in the linker defined place. Follow the ld.gold example and give
a multiple symbol definition error. The ld.bfd behaviour is to ignore the
definition in the input object and redefine it, which seems like it could
be more surprising.
fixes pr39587
Differential Revision: https://reviews.llvm.org/D54624
llvm-svn: 347854
|
|
|
|
|
|
|
|
|
| |
This is an reland of rL343155 which got reverted because
of a sphinx failure on the buildbot.
Differential Revision: https://reviews.llvm.org/D54982
llvm-svn: 347830
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
object file
Summary:
This reinstates what I originally intended to do in D54361.
It removes the assumption that .debug_gnu_pubnames has increasing CuOffset.
Now we do better than gold here: when .debug_gnu_pubnames contains
multiple sets, gold would think every set has the same CU index as the
first set (incorrect).
Reviewed By: ruiu
Reviewers: ruiu, dblaikie, espindola
Subscribers: emaste, arichardson, arphaman, llvm-commits
Differential Revision: https://reviews.llvm.org/D54483
llvm-svn: 347820
|
|
|
|
|
|
|
|
|
|
|
| |
This patch also makes getPltEntryOffset a non-member function because
it doesn't depend on any private members of the TargetInfo class.
I tried a few different ideas, and it seems this change fits in best to me.
Differential Revision: https://reviews.llvm.org/D54981
llvm-svn: 347781
|
|
|
|
| |
llvm-svn: 347751
|
|
|
|
| |
llvm-svn: 347750
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D54920
llvm-svn: 347742
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DT_PLTRELSZ dynamic tag is calculated using the size of the
OutputSection containing the In.RelaPlt InputSection. This will work for the
default no linker script case and the majority of linker scripts.
Unfortunately it doesn't work for some 'almost' sensible linker scripts. It
is permitted by ELF to have a single OutputSection containing both
In.RelaDyn, In.RelaPlt and In.RelaIPlt. It is also permissible for the range
of memory [DT_RELA, DT_RELA + DT_RELASZ) and the range
[DT_JMPREL, DT_JMPREL + DT_JMPRELSZ) to overlap as long as the the latter
range is at the end.
To support this type of linker script use the specific InputSection sizes.
Fixes pr39678
Differential Revision: https://reviews.llvm.org/D54759
llvm-svn: 347736
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The number of sections is used in assignAddresses (in
finalizeAddresses) and the space for all sections is permanent from
that point on, even if we later decide we won't write some of them.
The VirtualSize field also gets calculated in assignAddresses, so we
need to manually check whether the section is empty here instead.
Differential Revision: https://reviews.llvm.org/D54495
llvm-svn: 347704
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
|
|
|
|
| |
llvm-svn: 347680
|
|
|
|
| |
llvm-svn: 347678
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IFUNC symbols.
This is https://bugs.llvm.org/show_bug.cgi?id=38074.
The issue is that when calling a function, LLD generates a
.got entry that points to the IFUNC resolver function when
instead, it should use the PLT entries properly for
handling the IFUNC.
So we should create a got entry that points to PLT entry,
which itself loads the value from
.got.plt, relocated with R_*_IRELATIVE to make things work.
Patch do that.
Differential revision: https://reviews.llvm.org/D54314
llvm-svn: 347650
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes to the instructions performed by TLS relaxation and the errata
patching are performed with relocations. As these are applied so late the
errata scanning won't see the changes in the section data made by the TLS
relaxation. This can lead to a TLS relaxed sequence being patched when it
doesn't need to be.
The fix checks to see if there is a R_RELAX_TLS_IE_TO_LE instruction at the
same address as the ADRP as this indicates the presence of a relaxation
of a sequence that might get recognised as a patch.
Differential Revision: https://reviews.llvm.org/D54854
llvm-svn: 347649
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is https://bugs.llvm.org//show_bug.cgi?id=38978
Spec says that:
"Objects may be built with the -z nodefaultlib option to
suppress any search of the default locations at runtime.
Use of this option implies that all the dependencies of an
object can be located using its runpaths.
Without this option, which is the most common case, no
matter how you augment the runtime linker's library
search path, its last element is always /usr/lib for 32-bit
objects and /usr/lib/64 for 64-bit objects."
The patch implements this option.
Differential revision: https://reviews.llvm.org/D54577
llvm-svn: 347647
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
creating a PDB
GNU ld, which doesn't generate PDBs, can optionally generate a
build id by passing the --build-id option. LLD's MinGW frontend knows
about this option but ignores it, as I had falsely assumed that LLD
already generated build IDs even in those cases.
If debug info is requested and no PDB path is set, generate a
build id signature as a hash of the binary itself. This allows
associating a binary to a minidump, even if debug info isn't
written in PDB form by the linker.
Differential Revision: https://reviews.llvm.org/D54828
llvm-svn: 347645
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
MSVC does this, and we should to.
The .gfids table is a table of RVAs, so it's impossible for a DLL to
indicate that an imported symbol is address taken. Therefore, exports
appear to be listed as address taken by the DLL that exports them.
This fixes an issue that Firefox ran into here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1485016#c12
In Firefox, the export directive came from a .def file, but we need to
do this for any kind of export.
Reviewers: dmajor, hans, amccarth, alex
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54723
llvm-svn: 347623
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D54758
llvm-svn: 347621
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The benefits are:
a) Performance (very minor): it removes a heap allocation of the std::function constructor (template<class F> function(F f))
b) Clarity: it suggests that the callable's lifetime should end after the callee returns. Such callback is widely used in llvm. lld also uses it a lot.
Reviewers: ruiu, rnk, pcc
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54813
llvm-svn: 347620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hash. NFCI.
On my machine this reduced median link time of lld-speed-test/chrome
from 2.68s to 2.41s. It also reduces link time of Chrome for Android
with a prototype compiler change that causes the compiler to create
large numbers of identical (modulo relocations) sections from >15
minutes to a few seconds.
Differential Revision: https://reviews.llvm.org/D54773
llvm-svn: 347594
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: They have an additional `ThreadsEnabled` check, which does not matter much.
Reviewers: pcc, ruiu, rnk
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54812
llvm-svn: 347587
|
|
|
|
|
|
| |
We had no such test.
llvm-svn: 347553
|