SharedFile::parseRest function grew organically and got a bit hard to
understand. This patch refactor it. This patch also adds comments.
Differential Revision: https://reviews.llvm.org/D44860
llvm-svn: 328579
When the target saves ElfSym::GlobalOffsetTable in the .got rather than
.got.plt, Target->GotHeaderEntriesNum states the number of extra entries
required in the .got. Rather than having to add Target->GotHeaderEntriesNum to
NumEntries in every function which refers to NumEntries, this patch changes the
initial value of NumEntries in the constructor.
Differential Revision: https://reviews.llvm.org/D44744
llvm-svn: 328559
Currently, we might have a bug with scripts like below:
.foo : ALIGN(8)
{
*(.foo)
} > ram
because do not expand the memory region when doing ALIGN.
This might result in file range overlaps. The patch fixes the issue.
Differential revision: https://reviews.llvm.org/D44730
llvm-svn: 328479
Currently when we build input sections list in linker script
we ignore all rel[a] sections. That was done to support
scripts like .rela.dyn : { *(.rela.data) } for emit relocs.
Though as a result following scripts were also silently ignored:
/DISCARD/ : { *(.rela.plt)
/DISCARD/ : { *(.rela.dyn)
and we produced output with this sections. That is not ideal.
The solution this patch suggests is simple: do not ignore synthetic
rel[a] sections. That way we can enable common discarding logic
for them and report a proper error.
Differential revision: https://reviews.llvm.org/D41640
llvm-svn: 328419
Previously, we used 0 as an alias for VER_NDX_GLOBAL and had a dummy
entry in SharedFile::Verdefs so that the access to the array is within
its boundary. But that's not straightforwad. We can just stop doing both.
llvm-svn: 328401
Since SectionBase::getOutputSection handles ICF replaces and
SectionBase::getOffset was handling it in some cases, it is more
consistent to have getOffset always handle it.
llvm-svn: 328391
This was reverted several times due to what ultimately turned out
to be incompatibilities in our serialized hash table format.
Several changes went in prior to this to fix those issues since
they were more fundamental and independent of supporting injected
sources, so now that those are fixed this change should hopefully
pass.
llvm-svn: 328363
When investigating bugs in PDB generation, the first step is
often to do the same link with link.exe and then compare PDBs.
But comparing PDBs is hard because two completely different byte
sequences can both be correct, so it hampers the investigation when
you also have to spend time figuring out not just which bytes are
different, but also if the difference is meaningful.
This patch fixes a couple of cases related to string table emission,
hash table emission, and the order in which we emit strings that
makes more of our bytes the same as the bytes generated by MS PDBs.
Differential Revision: https://reviews.llvm.org/D44810
llvm-svn: 328348
When looking for the output section and the output offset the
expectation was that the caller had looked at Repl. That works fine
for InputSections, but in the case of MergeInputSections the caller
doesn't have the section that is actually replaced.
The original testcase was failing because getOutputSection was
returning null. The slightly extended testcase also checks that
getOffset also checks Repl.
I will send a refactoring separetelly.
llvm-svn: 328332
This fixes PR36367 which is about segfault when --emit-relocs is
used together with .eh_frame sections which happens because
of reordering of regular and .rel[a] sections.
Path changes loop that iterates over input sections to create
relocation target sections first.
Differential revision: https://reviews.llvm.org/D44679
llvm-svn: 328299
Currently lld just parses the .debug_line section assuming that there
is only one compile unit. That assumption is false (PR36793).
I have a patch that changes lld to iterate over the compile units and
parse the portions of the .debug_line they point to (which fixes
PR36793).
A problem is that we will then need a compiler unit pointing to
.debug_line for lld to see it.
It seems like bfd has the same restriction.
This patch updates existing tests to add a minimal compile unit so
that they still work with PR36793 fixed.
llvm-svn: 328215
The relocations R_PPC64_REL16_LO and R_PPC64_REL16_HA should return R_PC
for getRelExpr since they compute #lo(S + A – P) and #ha(S + A – P).
Differential Revision: https://reviews.llvm.org/D44648
llvm-svn: 328103
Patch teaches LLD to hint user about -fdebug-types-section flag
if relocation overflow happens in debug section.
Differential revision: https://reviews.llvm.org/D40954
llvm-svn: 328081
This is still failing on a different bot this time due to some
issue related to hashing absolute paths. Reverting until I can
figure it out.
llvm-svn: 328014
The issue causing this to fail in certain configurations
should be fixed.
It was due to the fact that DIA apparently expects there to be
a null string at ID 1 in the string table. I'm not sure why this
is important but it seems to make a difference, so set it.
llvm-svn: 328002
There are no reasons for them to be STV_DEFAULT,
recently bfd did the same change.
Differential revision: https://reviews.llvm.org/D44566
llvm-svn: 327983
It seems @LLVM_LIBXML2_ENABLED@ doesn't always get set to 0 when not available,
but to nothing, which broke parsing of lit.site.cfg.py.
> @LLVM_LIBXML2_ENABLED@ will be replaced with 0 or 1. Putting quotes
> around that is unnecessary and just makes it harder to use the value.
> This matches what have_zlib does below.
>
> This also puts the flag together with the feature-related ones instead
> of the path-related flags.
llvm-svn: 327966
@LLVM_LIBXML2_ENABLED@ will be replaced with 0 or 1. Putting quotes
around that is unnecessary and just makes it harder to use the value.
This matches what have_zlib does below.
This also puts the flag together with the feature-related ones instead
of the path-related flags.
llvm-svn: 327964
We do not have test showing we explicitly reject objects
where relocation section goes before the target, i.e
.rel[a].text is listed before .text, for example.
The patch adds it.
llvm-svn: 327963
Choosing a Shift2 value based on wordsize is cargo-culted from gold.
Assuming that djb hash is a good hash function, choosing bits [4,9]
shouldn't be any worse or better than choosing bits [5,10]. We shouldn't
have copied that behavior that we can't justify in the first place.
Differential Revision: https://reviews.llvm.org/D44547
llvm-svn: 327921
We found that when you pass --allow-multiple-definitions or `-z muldefs`
to GNU linkers, they don't complain about duplicate symbols at all. They
don't even print out warnings on it. We emit warnings in that case.
If you pass --fatal-warnings, that difference results in a link failure.
Differential Revision: https://reviews.llvm.org/D44549
llvm-svn: 327920
Natvis is a debug language supported by Visual Studio for
specifying custom visualizers. The /NATVIS option is an
undocumented link.exe flag which will take a .natvis file
and "inject" it into the PDB. This way, you can ship the
debug visualizers for a program along with the PDB, which
is very useful for postmortem debugging.
This is implemented by adding a new "named stream" to the
PDB with a special name of /src/files/<natvis file name>
and simply copying the contents of the xml into this file.
Additionally, we need to emit a single stream named
/src/headerblock which contains a hash table of embedded
files to records describing them.
This patch adds this functionality, including the /NATVIS
option to lld-link.
Differential Revision: https://reviews.llvm.org/D44328
llvm-svn: 327895
This patch adds changes to start supporting the Power 64-Bit ELF V2 ABI.
This includes:
- Changing the ElfSym::GlobalOffsetTable to be named .TOC.
- Creating a GotHeader so the first entry in the .got is .TOC.
- Setting the e_flags to be 1 for ELF V1 and 2 for ELF V2
Differential Revision: https://reviews.llvm.org/D44483
llvm-svn: 327871
This is the same as 327248 except Arm defining _GLOBAL_OFFSET_TABLE_ to
be the base of the .got section as some existing code is relying upon it.
For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be at
the start of the .got.plt section so that _GLOBAL_OFFSET_TABLE_[0] =
reserved value that is by convention the address of the dynamic section.
Previously we had defined _GLOBAL_OFFSET_TABLE_ as either the start or end
of the .got section with the intention that the .got.plt section would
follow the .got. However this does not always hold with the current
default section ordering so _GLOBAL_OFFSET_TABLE_[0] may not be consistent
with the reserved first entry of the .got.plt.
X86, X86_64 and AArch64 will use the .got.plt. Arm, Mips and Power use .got
Fixes PR36555
Differential Revision: https://reviews.llvm.org/D44259
llvm-svn: 327823
Reid pointed out the string table for supporting long section names is a
BFD extension and the comments should reflect that. Explicitly spell out
link.exe's and binutil's behavior around section names and the rationale
for LLD's behavior.
Differential Revision: https://reviews.llvm.org/D42659
llvm-svn: 327736
This change broke ARM code that expects to be able to add
_GLOBAL_OFFSET_TABLE_ to the result of an R_ARM_REL32.
I will provide a reproducer on llvm-commits.
llvm-svn: 327688
In COFF, duplicate string literals are merged by placing them in a
comdat whose leader symbol name contains a specific prefix followed
by the hash and partial contents of the string literal. This gives
us an easy way to identify sections containing string literals in
the linker: check for leader symbol names with the given prefix.
Any sections that are identified in this way as containing string
literals may be tail merged. We do so using the StringTableBuilder
class, which is also used to tail merge string literals in the ELF
linker. Tail merging is enabled only if ICF is enabled, as this
provides a signal as to whether the user cares about binary size.
Differential Revision: https://reviews.llvm.org/D44504
llvm-svn: 327668
This makes the design a little more similar to the ELF linker and
should allow for features such as ARM range extension thunks to be
implemented more easily.
Differential Revision: https://reviews.llvm.org/D44501
llvm-svn: 327667
Patch teaches LLD to print BYTE/SHORT/LONG/QUAD and
location move commands to the map file.
Differential revision: https://reviews.llvm.org/D44004
llvm-svn: 327612
I definitely didn't run the tests before committing :(
Most of these tests failed because the LLD map file output changed,
moving the functions from the main text section to a new per-function
section.
ICF also started to fire in a few cases, leading to new layouts.
llvm-svn: 327571
This is an option to print out a table of symbols and filenames.
The output format of this option is the same as GNU, so that it can be
processed by the same scripts as before after migrating from GNU to lld.
This option is mildly useful; we can live without it. But it is pretty
convenient sometimes, and it can be implemented in 50 lines of code, so
I think lld should support this option.
Differential Revision: https://reviews.llvm.org/D44336
llvm-svn: 327565
GNU ld has got a number of different flags for adjusting how to
behave around stdcall functions. The --kill-at flag strips the
trailing sdcall suffix from exported functions (which otherwise
is included by default in MinGW setups).
This also strips it from the corresponding import library though.
That makes it hard to link to such an import library from code
that calls the functions - but this matches what GNU ld does with
this flag. Therefore, this flag is probably not sensibly used
together with import libraries, but probably mostly when creating
some sort of plugin, or if creating the import library separately
with dlltool.
Differential Revision: https://reviews.llvm.org/D44292
llvm-svn: 327561
This tests that LLVM emits the relocations that /guard:cf needs to
identify address taken.
This was PR36624, which was fixed in r327557.
llvm-svn: 327559
This "fixes" PR36678 by just producing an error when we find a case
where we would produce an plt entry that used ebx but ebx would not be
set.
llvm-svn: 327542
This reduces the number of lookups to one per COMDAT group, rather than
one per symbol in a COMDAT group.
Differential Revision: https://reviews.llvm.org/D44344
llvm-svn: 327523
Previously, Config->InitialMemory/MaxMemory were hooked up to some
commandline args but had no effect at all.
Differential Revision: https://reviews.llvm.org/D44393
llvm-svn: 327508
Currently, we can end up with NBuckets==0 and android loader
does not like it (PR36537).
Seems we can go with a minimal amount of changes here for simplicity
and be consistent with gold and so just always use >= 1 value for NBuckets.
Differential revision: https://reviews.llvm.org/D44422
llvm-svn: 327481
Patch do the following changes:
* Test case was converted from MIPS to x86.
* Removed part of the test checking we are able to produce a valid output.
Since we do that already in other tests, this one's intention should be
only to check we are still able to report overlaps and/or produce
broken output with overlaps.
Differential revision: https://reviews.llvm.org/D44438
llvm-svn: 327480
This fixes issues found on the wasm waterfall related to relocations
with addends. Undefined symbols, even those with addends should
always have a provisional value of zero. At least this is what llvm
emits (and I believe this is true for ELF too).
Differential Revision: https://reviews.llvm.org/D44451
llvm-svn: 327468
This follows recently started direction and sometimes
allows to fully get rid from `echo` calls.
I'll rename changed files to *.test in a follow-up.
llvm-svn: 327410
Previously, Config->Demangle was uninitialised (not hooked up to
commandline handling)
Differential Revision: https://reviews.llvm.org/D44301
llvm-svn: 327390
This finishes PR35877.
INSERT BEFORE used similar to INSERT AFTER,
it inserts sections before the given target section.
Differential revision: https://reviews.llvm.org/D44380
llvm-svn: 327378
This is part of PR36515.
With some linkerscripts it is possible to get file offset overlaps
and overflows. Currently LLD checks overlaps in checkNoOverlappingSections().
And also we allow broken output with --no-inhibit-exec.
Problem is that sometimes final offset of sections is completely broken
and we calculate output file size wrong and might crash.
Patch implements check to verify that there is no output section
which offset exceeds file size.
Differential revision: https://reviews.llvm.org/D43819
llvm-svn: 327376
This fixes PR36598.
LLD currently crashes when we have empty output section
with SHF_LINK_ORDER flag. This might happen if we place an
empty synthetic section in the linker script, but keep output
section alive with the use of additional symbol, for example.
The patch fixes the issue by dropping all special flags
for empty sections.
Differential revision: https://reviews.llvm.org/D44376
llvm-svn: 327374
Currently lld creates plain plt entries when a R_386_PC32 resolves to
a symbol in a shared library. That is a bug (PR36678). Don't depend on
that behavior on this test.
llvm-svn: 327357
Verify that the location where a relocation is about the be
applied contains the expected existing value.
This is essentially a sanity check to catch bugs in the compiler
and the linker.
Differential Revision: https://reviews.llvm.org/D44349
llvm-svn: 327325
This bug was found by accident while trying to expand out testcases
for imported symbols, and is covered by the additional test case.
Differential Revision: https://reviews.llvm.org/D44331
llvm-svn: 327290
This matches the existing ordering that's been there for globals
for a while (__stack_pointer coming first).
Differential Revision: https://reviews.llvm.org/D44333
llvm-svn: 327286
This makes the output of some flag names in warning messages consistent with
the output of /? and the output of flags in most other diagnostics.
https://reviews.llvm.org/D44307
llvm-svn: 327261
AFTER keyword is mandatory and consume() was
used by mistake here. We accepted broken script before
this patch, testcase shows the issue.
llvm-svn: 327260
the start of the .got.plt section so that _GLOBAL_OFFSET_TABLE_[0] =
reserved value that is by convention the address of the dynamic section.
Previously we had defined _GLOBAL_OFFSET_TABLE_ as either the start or end
of the .got section with the intention that the .got.plt section would
follow the .got. However this does not always hold with the current
default section ordering so _GLOBAL_OFFSET_TABLE_[0] may not be consistent
with the reserved first entry of the .got.plt.
X86, X86_64, Arm and AArch64 will use the .got.plt. Mips and Power use .got
Fixes PR36555
Differential Revision: https://reviews.llvm.org/D44259
llvm-svn: 327248
toString(T) is a stringize function for an object of type T. Each type
that has that function defined should know how to stringize itself, and
there should be one string representation of an object. Passing a
"supplemental" argument to toString() breaks that princple. We shouldn't
add a second parameter to that function.
Differential Revision: https://reviews.llvm.org/D44323
llvm-svn: 327182
This avoids creating multiple thunks for symbols with aliases or which
belong to ICF'd sections. This patch reduces the size of Chromium for
Android by 260KB (0.8% of .text).
Differential Revision: https://reviews.llvm.org/D44284
llvm-svn: 327154
This error case is described in Linking.md. The operand for call requires
generation of a synthetic stub.
Differential Revision: https://reviews.llvm.org/D44028
llvm-svn: 327151
Previously we created __wasm_call_ctors with null InputFunction, and
added the InputFunction later. Now we create the SyntheticFunction with
null body, and set the body later.
Differential Revision: https://reviews.llvm.org/D44206
llvm-svn: 327149
In what appears to be a copy-and-paste error, lld currently only
installs libraries if the lld tools are configured to build.
Instead, lld should allow the libraries to be installed even if the lld
tools are not being built. Additionally, if users want to only install
the tools and not the libraries, the LLVM way of doing that is by
checking for LLVM_INSTALL_TOOLCHAIN_ONLY.
This fixes PR35960.
llvm-svn: 327126
This fixes the broken tests that were causing failures. The tests
before were verifying that the time stamp was 0, but now that we
are actually writing a timestamp, I just removed the match against
the timestamp value.
llvm-svn: 327049
Our code assumes all input sections in an output SHF_LINK_ORDER
section has SHF_LINK_ORDER flag. We do not check that and that can cause a crash.
That happens because we call
std::stable_sort(Sections.begin(), Sections.end(), compareByFilePosition);,
where compareByFilePosition predicate does not expect to see
null when calls getLinkOrderDep.
The same might happen when sections refer to non-regular sections.
Test cases demonstrate the issues, patch fixes them.
Differential revision: https://reviews.llvm.org/D44193
llvm-svn: 327006
This implements INSERT AFTER in a following way:
During reading scripts it collects all insert statements.
After we done and read all files it inserts statements into script commands list.
With that:
* Rest of code does know nothing about INSERT.
* Approach is straightforward and have no visible limitations.
* It is also easy to support INSERT BEFORE (was seen in clang code once).
* Should work for PR35877 and similar cases.
Cons:
* It assumes we have "main" scripts that describes sections.
Differential revision: https://reviews.llvm.org/D43468
llvm-svn: 327003
We don't need to handle an object file having more than one symbol table,
so as soon as we find the first one, we can process it and then return
from the function.
llvm-svn: 326977
When a symbol is exported via --export=foo but --allow-undefined
is also specified, the symbol is now allowed to be undefined.
Previously we were special casing such symbols.
This combinations of behavior is exactly what emescripten
requires. Although we are trying hard not to allow emscripten
specific features in lld, this one makes sense.
Enforce this behavior by added this case to test/wasm/undefined.ll.
Differential Revision: https://reviews.llvm.org/D44237
llvm-svn: 326976
addElfSymbols and readJustSymbolsFile still has duplicate code, but
I didn't come up with a good idea to eliminate them. Since this patch
is an improvement, I'm sending this for review.
Differential Revision: https://reviews.llvm.org/D44187
llvm-svn: 326972
Windows tools treats the timestamp fields as sort of a build id,
using it to archive executables on a symbol server, as well as
for matching executables to PDBs. We were writing 0 for these
fields, which would cause symbol servers to break as they are
indexed in the symbol server based on this value.
Although the field is called timestamp, it can really be any
value that is unique per build, so to support reproducible builds
we use a hash of the executable here.
Differential Revision: https://reviews.llvm.org/D43978
llvm-svn: 326920
It was raised during the review of D43819.
LLD usually use [X, Y] for reporting ranges, like below:
"relocation R_386_16 out of range: 65536 is not in [0, 65535]"
Patch changes rangeToString() to do the same.
Differential revision: https://reviews.llvm.org/D44207
llvm-svn: 326918
Summary:
I originally tried to simplify code and then noticed that lld doesn't
do what it tells to the user by warn(). It says "unable to order
discarded symbol" but it actually can for sections eliminated by ICF.
With this patch, lld doesn't sort such sections.
Reviewers: jhenderson, rafael
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D44180
llvm-svn: 326911
LLD uses the debug info and debug line sections to determine the location of
e.g. references to undefined symbols, when producing error messages. In the
event that debug info was present, but debug line parsing failed for some
reason, then a nullptr would end up being dereferenced by the location-lookup
code.
Differential Revision: https://reviews.llvm.org/D44205
Reviewers: grimar
llvm-svn: 326899
With fix: add missing "RUN:" prefix to test case.
Original commit message:
We do not report LMA region overflows currently.
Both GNU linkers do that. The patch implements it.
Differential revision: https://reviews.llvm.org/D44094
llvm-svn: 326895
We do not report LMA region overflows currently.
Both GNU linkers do that. The patch implements it.
Differential revision: https://reviews.llvm.org/D44094
llvm-svn: 326892
Currently, LLD segfaults when linker script attempts to discard
one of the hash sections. This patch fixes that.
Differential revision: https://reviews.llvm.org/D44012
llvm-svn: 326891
It looks like the problem that caused us to originally warn instead of
error was that of a symbol being assigned to the same version twice.
Now we don't warn if a symbol is assigned to the same version twice,
but error if it is assigned to multiple.
This fixes pr28342.
llvm-svn: 326813
We do not expand memory region correctly for following scripts:
.foo.1 :
{
*(.foo.1)
. += 0x1000;
} > ram
Patch generalizes expanding of output sections and memory
regions in one place and fixes the issue.
Differential revision: https://reviews.llvm.org/D43999
llvm-svn: 326688
"division by zero" or "modulo by zero" are not
very informative errors and even probably confusing
as does not let to know that error is coming from linker script.
Patch adds location reporting.
Differential revision: https://reviews.llvm.org/D43934
llvm-svn: 326686
This avoids the Writer unnecessarily having a member to retain ownership
of the function body.
Differential Revision: https://reviews.llvm.org/D43933
llvm-svn: 326580
LLD can not catch a memory area overflow when using a data command.
If we have the script below:
.foo :
{
*(.foo)
BYTE(0x1)
} > ram
where BYTE overflows the ram region, we do not report it currently.
Patch fixes that.
Differential revision: https://reviews.llvm.org/D43948
llvm-svn: 326545
Also remove the space between --lto-O and value, as the option with a
space is not accepted at present.
Leave --opt-remarks-filename as it does not currently accept the = form.
llvm.org/pr36563
llvm-svn: 326536
GNU linkers by convention supports both `--foo bar` and `--foo=bar` styles
for all long options that take arguments.
Differential Revision: https://reviews.llvm.org/D43972
llvm-svn: 326506
Summary:
If an executable needs text relocations, it should be marked as such so
that the loader can prepare for text relocations. We currently create a
dummy segment with DT_TEXTREL for that purpose.
Generic ABI as of 2000 [1] mentioned that "Its [DT_TEXTREL's] use
has been superseded by the DF_TEXTREL flag". However, it's actually not
superseded even after 18 years. OpenBSD and musl recognize only DT_TEXTREL.
So we still need to set both.
[1] http://www.sco.com/developers/gabi/2000-07-17/ch5.dynamic.html
Reviewers: rafael
Subscribers: emaste, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D43920
llvm-svn: 326503
The argument is section=address, not just address.
(For compatibility with GNU linkers we need to, but do not yet, accept
--section-start=section=address.)
llvm-svn: 326463
We intend to maintain compatibility with GNU ld, and in the GNU world
long options are conventionally specified as --long-option=value. For
whatever reason GNU ld.bfd accepts both --long-option value and
--long-option=value, but documents the former. Follow suit.
Some lld long options do not accept the = form; this is probably a bug
to be fixed (along with a man page update).
Reported by Ingo Schwarze, for --entry.
llvm-svn: 326459
For now this is NFC, but this small refactor opens the door to
letting us embed a hash of the PDB in the build id field of the
PDB.
Differential Revision: https://reviews.llvm.org/D43913
llvm-svn: 326453
With the current code if the script has a PHDRS we always obey and try
to allocate a header. This can cause Min - HeaderSize to underflow.
It looks like bfd actually prints an error for this case. With this
patch we do the same.
Found while looking at pr36515.
llvm-svn: 326441
LLD crashes with broken scripts shown in testcase,
because fails to read memory regon name and accesses
MemoryRegions's element which is nullptr.
Patch fixes it.
Differential revision: https://reviews.llvm.org/D43866
llvm-svn: 326431
This is PR36515.
Currenly if we have a script like .debug_info 0 : { *(.debug_info) },
we would not remove this section and keep it in the output.
That does not work, because it is common case for
debug sections to have a zero address expression.
Patch changes behavior so that we remove only sections
that do not use symbols in its expressions.
Differential revision: https://reviews.llvm.org/D43863
llvm-svn: 326430
Previously, we didn't try to make effort to put .note sections next
to each other in the output file, so two .note sections were likely
to be stored to two separate NOTE segments. That's undesirable because
we should create as few segments as possible in general.
Differential Revision: https://reviews.llvm.org/D43858
llvm-svn: 326410
It now includes both linkerscript and non linkerscript variants.
Extracted from a patch by Rui while I was trying to figure out what
exactly was changing.
llvm-svn: 326409
Summary:
This change removes large "echo" commands from the test by writing
tests themselves as linker scripts.
Reviewers: rafael
Subscribers: emaste, javed.absar, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D43900
llvm-svn: 326403
Some linker script test cases contain only a few lines of assembly
and a long linker script. Such tests are easier to maintain if we
write the main test file as a linkier script instead of assembly.
Differential Revision: https://reviews.llvm.org/D43887
llvm-svn: 326363
When merging in types from a type server PDB, we would use a
pointer into the type server PDB's mapped file buffer directly
to avoid copying data. However, we would close the type server
PDB after we finished merging in its types, which would unmap
all of its memory. This would lead to a use after free.
We fix this by making a strong reference in the PDBLinker class
to all referenced type server PDBs, thereby making it safe to
hold pointers into its memory mapped contents.
This fixes llvm.org/pr36455
Differential Revision: https://reviews.llvm.org/D43834
llvm-svn: 326345
This should resolve the issue that lld build fails in some hosts
that uses case-insensitive file system.
Differential Revision: https://reviews.llvm.org/D43788
llvm-svn: 326339
Let X and Y be types. Previously, functions F(X, Y) and G(Y, X) had
the same hash value because their hash values are computed as follows:
hash(F) = hash(X) + hash(Y)
hash(G) = hash(Y) + hash(X)
This patch fixes the issue by using hash_combine.
Differential Revision: https://reviews.llvm.org/D43856
llvm-svn: 326336
Update LLD test expectations for new symbol ordering introduced by
Differential D43685.
Differential Revision: https://reviews.llvm.org/D43875
llvm-svn: 326335
We should process symbols inside output section declarations the same way as top-level ones.
Differential Revision: https://reviews.llvm.org/D43008
llvm-svn: 326305
This patch simplifies initializeSymbols. Since that function is called
at the tail context of ObjFile::parse, and the function is called only
once from that function, that's effectively just a continuation of
ObjFile::parse. So this patch merge it with ObjFile::parse.
Differential Revision: https://reviews.llvm.org/D43848
llvm-svn: 326296
The problem I want to address now is that chunks have too many data
members for "offsets", and their origins are not well defined.
For example, InputSegment has OutputSegmentOffset, but it's base class
also has OutputOffset. That's very confusing.
Differential Revision: https://reviews.llvm.org/D43726
llvm-svn: 326291
These output section names are ELF-specific. We shouldn't have this rule
for WebAssembly.
Differential Revision: https://reviews.llvm.org/D43712
llvm-svn: 326289
SubSection inherited from SyntheticSection, and SyntheticSection inherits
from OutputSection, so SubSection was an OutputSection. But that's wrong
because SubSection is not actually a WebAssembly output section.
It shares some functionalities with OutputSection, but overall it's very
different.
This patch removes that inheritance.
Differential Revision: https://reviews.llvm.org/D43719
llvm-svn: 326286
FileOutputBuffer automatically removes an existing file, so we don't
need to do that. Actually doing that is discouraged because when the
linker fails to create an output for some reason after instantiating
FileOutputBufffer, FileOutputBuffer removes a temporary file and don't
touch an existing file. That's an desired behavior from the user's
point of view.
(Internally, FileOutputBuffer writes its contents to a temporary file
and then rename it over to an existing file on commit()).
Differential Revision: https://reviews.llvm.org/D43728
llvm-svn: 326281
Looks like these accessor functions are a bit overly defensive, and
due to the amount of code, that part isn't easy to read. We have
code to log translation results in writeTo and writeRelocations, so
I don't think we need to log it again in these functions.
I think the new function is much easier to understand.
Differential Revision: https://reviews.llvm.org/D43713
llvm-svn: 326277
Instead of {Function,Global,Data}Symbol, use Defined{Function,Global,Data}
because undefined symbol should never reach this function.
Differential Revision: https://reviews.llvm.org/D43710
llvm-svn: 326275
I think calling reserve() for each object file is too many and isn't useful.
We can add reserve() later. By default, we shouldn't add reserve() to a lot
of places.
Differential Revision: https://reviews.llvm.org/D43722
llvm-svn: 326273
Previously, one function adds all types of undefined symbols. That
doesn't fit to the wasm's undefined symbol semantics well because
different types of undefined symbols are very different in wasm.
As a result, separate control flows merge in this addUndefined function
and then separate again for each type. That wasn't easy to read.
This patch separates the function into three functions. Now it is pretty
clear what we are doing for each undefined symbol type.
Differential Revision: https://reviews.llvm.org/D43697
llvm-svn: 326271
This means we don't need to write the linking metadata section
at all for executable (non-relocatable) output.
Differential Revision: https://reviews.llvm.org/D42869
llvm-svn: 326268
Summary:
Some of the tests invoke llvm-readelf. This currently appears to work
probably because the LLVM binary directory is included in $PATH. However,
this is quite fragile so let's just make lit expand the full path.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43827
llvm-svn: 326257
Imagine that we have sections A, B, C, where A == C and
symbol ordering file containing symbols: symC, symB, symA
Previously because of ICF it was possible that final order would be
B, A or B, C. That violates order specified in ordering file.
Patch changes that.
Differential revision: https://reviews.llvm.org/D43234
llvm-svn: 326179
It should be possible to resolve undefined symbols in dynamic libraries
using symbols defined in a linker script.
Differential Revision: https://reviews.llvm.org/D43011
llvm-svn: 326176
These are required for handling circular dependencies between
static libraries, which is something that lld-link always does without
any extra parameters.
Differential Revision: https://reviews.llvm.org/D43786
llvm-svn: 326172
This fixes pr36475.
I think this code can be simplified a bit, but I would like to check
in the more direct fix if we are in agreement on the direction and
then refactor.
This is not something that bfd does. The issue is not noticed in bfd
because it keeps fewer sections from the linkerscript in the output.
The reasons why it seems reasonable to do this:
- As George noticed, we would still keep the flags if the output
section had both an empty synthetic section and a regular section
- We need an heuristic to find the flags of output sections. Using the
flags of a synthetic section that would have been there seems a
reasonable heuristic.
llvm-svn: 326137
This patch removes the HashString function from StringExtraces and
replaces its uses with calls to djbHash from DJB.h.
This change is *almost* NFC. While the algorithm is identical, the
djbHash implementation in StringExtras used 0 as its default seed while
the implementation in DJB uses 5381. The latter has been shown to result
in less collisions and improved avalanching and is used by the DWARF
accelerator tables.
Because some test were implicitly relying on the hash order, I've
reverted to using zero as a seed for the following two files:
lld/include/lld/Core/SymbolTable.h
llvm/lib/Support/StringMap.cpp
Differential revision: https://reviews.llvm.org/D43615
llvm-svn: 326091
It looks like some of our tests depend on the ordering of hashed values.
I'm reverting my changes while I try to reproduce and fix this locally.
Failing builds:
lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/18388
lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/6743
lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/15607
llvm-svn: 326082
This removes the HashString function from StringExtraces and replaces
its uses with calls to djbHash from DJB.h
This is *almost* NFC. While the algorithm is identical, the djbHash
implementation in StringExtras used 0 as its seed while the
implementation in DJB uses 5381. The latter has been shown to result in
less collisions and improved avalanching.
https://reviews.llvm.org/D43615
(cherry picked from commit 77f7f965bc9499a9ae768a296ca5a1f7347d1d2c)
llvm-svn: 326081
MIPS ABIs require that if an executable file uses non-PIC model, the
EI_ABIVERSION entry in the ELF header should be incremented from 0 to 1.
That allows obsoleted / limited dynamic linkers refuse to link them.
llvm-svn: 325890
This continues direction started in D43069.
We can keep sections that are explicitly assigned to segment in script.
It helps to simplify code.
Differential revision: https://reviews.llvm.org/D43571
llvm-svn: 325887
Latest patch version now.
Original commit message:
[ELF] - Do not crash with --emit-relocs and --icf=all together.
Previously we would crash because did not mark .rel[a] sections
as dead and they tried to access parent which was not live
after ICF and therefore was null.
Differential revision: https://reviews.llvm.org/D43241
llvm-svn: 325879
Previously we would crash because did not mark .rel[a] sections
as dead and they tried to access parent which was not live
after ICF and therefore was null.
Differential revision: https://reviews.llvm.org/D43241
llvm-svn: 325877
This is for fixing PR36297.
Issue itself is that if we have SECTIONS { .bar (a+b) : { *(.stub) } };
script and no section .stub, when LLD will remove .bar, but
produce output with undefined symbols a and b.
Differential revision: https://reviews.llvm.org/D43069
llvm-svn: 325875
This is relative to "Bug 36166 - tools/gold/X86/comdat.ll is failing only on Debian Unstable" (PR36166).
Something changed in newer versions of gold and now together with gold-plugin
there is an issue shown in PR, symbol may get wrong visibility.
LLD works fine, but we have no testcase for the same use case, patch adds it.
Differential revision: https://reviews.llvm.org/D43193
llvm-svn: 325874
This responds to PR36475,
r325763 led to unexprected layout change, though
new behavior seems to be more correct.
Previously we could have following script:
.foo : { *(.foo) }
.bar : { *(.synthetic_empty) BYTE(0x11) }}
where synthetic_empty is a synthetic section which is empty and
hence removed by linker.
Before r325763 .bar would receive section flags from .synthetic_empty,
but after this revision it receives flags the same as .foo section has.
It is the same as if there would not be any synthetic_empty section in a script,
so looks reasonable and consistent behavior:
.foo : { *(.foo) }
.bar : { BYTE(0x11) }}
Patch adds testcase to document it.
Differential revision: https://reviews.llvm.org/D43632
llvm-svn: 325873
We have an internal program that does't link without this patch. I don't
know of any open-source program that needs this, but there might be.
Since this patch improves compatibility with GNU linkers with a few lines
of code, I think it's worth to be committed.
The problem is about undefined symbols in DSOs. Some programs depend on
the GNU linkers' behavior that they pull out object files from archive
files to resolve undefined symbols in DSOs. We already allow that kind of
"reverse" dependency (from DSOs to the main executable) for regular
symbols, in particular, for "__progname" symbol (which is usually in
crt0.o), but that doesn't work if the symbol is in an archive file.
This patch is to make it work.
Differential Revision: https://reviews.llvm.org/D43658
llvm-svn: 325849
We sometimes need to iterate over input sections for a given
output section. It is not very convinent because we have to iterate
over section descriptions.
Patch introduces getInputSections helper, it simplifies things.
Differential revision: https://reviews.llvm.org/D43574
llvm-svn: 325763
This reverts commit r325679 that was committed without discussion.
Actually, in the discussion thread, most people opposed to have this
option in lld. Reverting that change doesn't mean that this is a
final decision, but that needs to be discussed first.
llvm-svn: 325714
Address @ruiu's post commit review comment about a value which is intended
to be a unsigned 32 bit integer as using uint32_t rather than unsigned.
llvm-svn: 325713
lld uses an arena allocator to one of allocations
like these can just use make<>.
Differential Revision: https://reviews.llvm.org/D43587
llvm-svn: 325706
In r324043, --nopie was renamed to --no-pie to presumably fix a typo.
As it turns out, "nopie" wasn't a typo but the spelling used by
OpenBSD's binutils ld. Gold on the other hand spells the flag "no-pie".
(Vanilla binutils doesn't have a flag like this at all.)
Since they do the same thing, let's support both spellings.
llvm-svn: 325679
This removes script input file and inlines script into
testcase body. That is consistent with othet LS tests
and makes testcase easier to read.
llvm-svn: 325673
Summary:
This fixes two failing tests on Windows with an installed version of python that has spaces in the path.
* elf/lto/cache.ll
* mach-o/dependency_info.yaml
Reviewers: zturner, llvm-commits, stella.stamenova
Subscribers: emaste, arichardson
Differential Revision: https://reviews.llvm.org/D43265
llvm-svn: 325650
This patch provides migitation for CVE-2017-5715, Spectre variant two,
which affects the P5600 and P6600. It implements the LLD part of
-z hazardplt. Like the Clang part of this patch, I have opted for that
specific option name in case alternative migitation methods are required
in the future.
The mitigation strategy suggested by MIPS for these processors is to use
hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard
barrier variants of the 'jalr' and 'jr' instructions respectively.
These instructions impede the execution of instruction stream until
architecturally defined hazards (changes to the instruction stream,
privileged registers which may affect execution) are cleared. These
instructions in MIPS' designs are not speculated past.
These instructions are defined by the MIPS32R2 ISA, so this mitigation
method is not compatible with processors which implement an earlier
revision of the MIPS ISA.
For LLD, this changes PLT stubs to use 'jalr.hb' and 'jr.hb'.
Reviewers: atanasyan, ruiu
Differential Revision: https://reviews.llvm.org/D43488
llvm-svn: 325647
Purely a rename in preparation for adding new global symbol type.
We want to use GlobalSymbol to represent real wasm globals and
DataSymbol for pointers to things in linear memory (what ELF would
call STT_OBJECT).
This reduces the size the patch to add the explicit symbol table
which is coming soon!
Differential Revision: https://reviews.llvm.org/D43476
llvm-svn: 325645
Previously wasm used a separate header to declare markLive
and ELF used to declare ICF. This change makes each backend
consistently declare these in their own headers.
Differential Revision: https://reviews.llvm.org/D43529
llvm-svn: 325631
The profailing style in lld seem to be to not include such empty lines.
Clang-tidy/clang-format seem to handle this just fine.
Differential Revision: https://reviews.llvm.org/D43528
llvm-svn: 325629
I think if statements that end with return is easier to read than
cascaded if-else-if-else-if statements because it makes clear that
execution of a function terminates there. This patch also adds more
blank lines to separate code blocks to meaningful pieces.
Differential Revision: https://reviews.llvm.org/D43517
llvm-svn: 325625
Summary:
With D43396, no clients use the Path parameter anymore.
This is the lld side fix with D43400.
Depends on D43396 and D43400.
Reviewers: pcc
Subscribers: emaste, inglorion, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D43401
llvm-svn: 325620
This header used to be needed here for the `OutRelocation` struct
but that no longer exists.
Differential Revision: https://reviews.llvm.org/D43516
llvm-svn: 325608
Instead include InputFuction and InputSegment directly
in the subclasses that use them (DefinedFunction and
DefinedGlobal).
Differential Revision: https://reviews.llvm.org/D43493
llvm-svn: 325603
This patch removes `OutRelocations` vector from the InputChunk and
directly consume `Relocations` vector instead. This should make the linker
faster because we don't create a temporary data structure, and it matches
the lld's design principle that we don't create temporary data structures
for object files but instead directly consume mmap'ed data whenever possible.
Differential Revision: https://reviews.llvm.org/D43491
llvm-svn: 325549
Summary:
Before the name of the function sounded like it was just a getter for the
private class member Addend. However, it actually calculates the final
value for the r_addend field in Elf_Rela that is used when writing the
.rela.dyn section. I also added a comment to the UseSymVA member to
explain how it interacts with computeAddend().
Differential Revision: https://reviews.llvm.org/D43161
llvm-svn: 325485
We already have isa<> for this, and these methods were simply
duplicating those redundantly.
Differential Revision: https://reviews.llvm.org/D43422
llvm-svn: 325418
Currently, archive file name is missing in this message. In general,
we should avoid constructing strings in an ad-hoc manner and instead
use toString() to get consistent output strings.
Differential Revision: https://reviews.llvm.org/D43420
llvm-svn: 325416
We are running lld tests with "--full-shutdown" option because we don't
want to call _exit() in lld if it is running tests. Regular shutdown
is needed for leak sanitizer.
This patch changes the way how we tell lld that it is running tests.
Now "--full-shutdown" is removed, and LLD_IN_TEST environment variable
is used instead.
This patch enables full shutdown on all ports, e.g. ELF, COFF and wasm.
Previously, we enabled it only for ELF.
Differential Revision: https://reviews.llvm.org/D43410
llvm-svn: 325413
Invoking lld as ld.lld, ld.ld64, lld-link or wasm-ld is preferred
than invoking lld as lld and pass an -flavor option. We have "lld"
file mostly for historical reasons.
Differential Revision: https://reviews.llvm.org/D43407
llvm-svn: 325405
This is required after r325399:
- EF_AMDGPU_ARCH_GCN got removed
- In the test, EF_AMDGPU_ARCH_GCN is replaced with EF_AMDGPU_MACH_AMDGCN_GFX803
llvm-svn: 325400
Summary:
- Makes code more in line with LLVM style (e.g. const char * -> StringRef)
- Do not use formatv since we can construct message just by `+`
- Replace some odd types such as `const StringRef` with more common type
- Do not use default arguments if they are not necessary
Reviewers: sbc100
Subscribers: jfb, aheejin, llvm-commits, sunfish
Differential Revision: https://reviews.llvm.org/D43403
llvm-svn: 325383
There seems to be no reason to collect this list of symbols.
Also fix a bug where --exclude-libs would apply to all symbols that
appear in an archive's symbol table, even if the relevant archive
member was not added to the link.
Differential Revision: https://reviews.llvm.org/D43369
llvm-svn: 325380
Newer versions of the gnu assembler produce a X86_64_PLT32 for
calls. There is a change under review in llvm to do the same, so update
the tests to not depend on it.
We can still produce a R_X86_64_PC32 with ".long foo - .".
llvm-svn: 325379
This bug effected undefined symbols that were resolved by
existing defined symbols. We were skipping the signature
check in this case.
Differential Revision: https://reviews.llvm.org/D43399
llvm-svn: 325376
Now that we have R_ADDEND, UseSymVA was redundant. We only want to
write the symbol virtual address when using an expression other than
R_ADDEND.
llvm-svn: 325360
Reviewed by: rafael
Differential Revision: https://reviews.llvm.org/D43336
There is some discussion as to the exact behaviour of combining ICF and
--symbol-ordering-file, but it seems beneficial to warn when attempting
to order the removed symbol regardless of the preferred approach.
llvm-svn: 325333
Summary:
This follows up on r321889 where writing of Elf_Rel addends was partially
moved to RelocationBaseSection. This patch ensures that the addends are
always written to the output section when a input section uses RELA but the
output is REL.
Differential Revision: https://reviews.llvm.org/D42843
llvm-svn: 325328
Previously, we accidentally dropped STB_WEAK bit from an undefined symbol
if there is a lazy object symbol with the same name. That caused a
compatibility issue with GNU gold.
llvm-svn: 325316
Even though it doesn't make sense, there seems to be multiple programs
in the wild that create PC-relative relocations in non-ALLOC sections.
I believe this is caused by the negligence of GNU linkers to not report
any errors for such relocations.
Currently, lld emits warnings against such relocations and exits.
So, you cannot link any program that contains wrong relocations until
you fix an issue in a program that generates wrong ELF files. It's often
impractical to fix a program because it's not always easy.
This patch relaxes the error checking and emit a warning instead.
Differential Revision: https://reviews.llvm.org/D43351
llvm-svn: 325307
When we are emitting a relocatable output, we should keep the original
symbol name including "@" part. Previously, we drop that part unconditionally
which resulted in dropping versions from symbols.
Differential Revision: https://reviews.llvm.org/D43307
llvm-svn: 325204
This was causing GCC builds with fail with:
Symbols.h:240:3: error: static assertion failed: Symbol types must be
trivially destructible
static_assert(std::is_trivially_destructible<T>(
The reason this is a gcc-only failure is that OptionalStorage has
as specialization for POD types that isn't built under GCC.
Differential Revision: https://reviews.llvm.org/D43317
llvm-svn: 325185
This patch addresses a minor compatibility issue with GNU linkers.
Previously, --export-dynamic-symbol is completely ignored if you
pass --export-dynamic together.
Differential Revision: https://reviews.llvm.org/D43266
llvm-svn: 325152
This brings wasm into line with ELF and COFF in terms of
symbol types are represented.
Differential Revision: https://reviews.llvm.org/D43112
llvm-svn: 325150
There are a number of different situations when symbols are requested
to be ordered in the --symbol-ordering-file that cannot be ordered for
some reason. To assist with identifying these symbols, and either
tidying up the order file, or the inputs, a number of warnings have
been added. As some users may find these warnings unhelpful, due to how
they use the symbol ordering file, a switch has also been added to
disable these warnings.
The cases where we now warn are:
* Entries in the order file that don't correspond to any symbol in the input
* Undefined symbols
* Absolute symbols
* Symbols imported from shared objects
* Symbols that are discarded, due to e.g. --gc-sections or /DISCARD/ linker script sections
* Multiple of the same entry in the order file
Reviewed by: rafael, ruiu
Differential Revision: https://reviews.llvm.org/D42475
llvm-svn: 325125
We sort inside output sections, so all the sections we see should be
InputSectionBase.
I noticed the patch adding callgraph based section ordering used this
type and changing this separately makes the merge easier.
llvm-svn: 325094
SetVector guarantees ordering, so with that we can get a deterministic
output for error messages.
Differential Revision: https://reviews.llvm.org/D43254
llvm-svn: 325064
Summary:
This protects calls to longjmp from transferring control to arbitrary
program points. Instead, longjmp calls are limited to the set of
registered setjmp return addresses.
This also implements /guard:nolongjmp to allow users to link in object
files that call setjmp that weren't compiled with /guard:cf. In this
case, the linker will approximate the set of address taken functions,
but it will leave longjmp unprotected.
I used the following program to test, compiling it with different -guard
flags:
$ cl -c t.c -guard:cf
$ lld-link t.obj -guard:cf
#include <setjmp.h>
#include <stdio.h>
jmp_buf buf;
void g() {
printf("before longjmp\n");
fflush(stdout);
longjmp(buf, 1);
}
void f() {
if (setjmp(buf)) {
printf("setjmp returned non-zero\n");
return;
}
g();
}
int main() {
f();
printf("hello world\n");
}
In particular, the program aborts when the code is compiled *without*
-guard:cf and linked with -guard:cf. That indicates that longjmps are
protected.
Reviewers: ruiu, inglorion, amccarth
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43217
llvm-svn: 325047
It seems redundant to store this information twice. None of the
locations where this bit is checked care about the distinction.
Differential Revision: https://reviews.llvm.org/D43250
llvm-svn: 325046
These were duplicating (incorrectly) some of the logic for
handling conflicts, but since they are only ever added right
at the start we can assume no existing symbols.
Also rename these methods for clarity.
Differential Revision: https://reviews.llvm.org/D43252
llvm-svn: 325045
This adds an extra level of static safety to our use of placement
new to allocate Symbol types. It prevents the accidental addition
on a non-trivially-destructible member that could allocate and
leak memory.
From the spec: Storage occupied by trivially destructible objects
may be reused without calling the destructor.
Differential Revision: https://reviews.llvm.org/D43244
llvm-svn: 325025
In order to identify a compressed section, we check if a section name
starts with ".zdebug" or the section has SHF_COMPRESSED flag. We already
use the knowledge in this function. So hiding that check in
isCompressedELFSection doesn't make sense.
llvm-svn: 324951
When decompressing a compressed debug section, we drop SHF_COMPRESSED
flag but we didn't drop "z" in ".zdebug" section name. This patch does
that for consistency.
This change also fixes the issue that .zdebug_gnu_pubnames are not
dropped when we are creating a .gdb_index section.
llvm-svn: 324949
GNU gold doesn't print out ICF sections for -verbose. It only shows
them for -print-icf-sections. We printed out them for -verbose because
we didn't have -print-icf-sections. Now that we have the option, there's
no reason to print out for -verbose.
Differential Revision: https://reviews.llvm.org/D43100
llvm-svn: 324755
This is for compatiblity with GNU gold. GNU gold tries to resolve
symbols specified by --export-dynamic-symbol. So, if a symbol specified
by --export-dynamic-symbol is in an archive file, lld's result is
currently different from gold's.
Interestingly, that behavior is different for --dynamic-list.
I added a new test to ensure that.
Differential Revision: https://reviews.llvm.org/D43103
llvm-svn: 324752
This is a bit more verbose, but it has a few advantages.
The logic on what to do with special sections like .init_array is not
duplicated. Before we would need keep isKnownNonreorderableSection in
sync.
I think with this the call graph based sorting can be implemented by
"just" returning a new order from buildSectionOrder.
llvm-svn: 324744
Bob Haarman