/FIXED:NO is always the default, so that part needs no work.
Also test the interaction of /ORDER: with /INCREMENTAL.
https://reviews.llvm.org/D45091
llvm-svn: 328877
As of rL215127, FileCheck has an -allow-empty flag,
so this could be used instead of writing a dummy line.
But it looks like the log is never empty now, so not
even that is needed.
llvm-svn: 328862
I tried a few different designs to find a way to implement it without
too much hassle and settled down with this. Unlike before, object files
given as arguments for --just-symbols are handled as object files, with
an exception that their section tables are handled as if they were all
null.
Differential Revision: https://reviews.llvm.org/D42025
llvm-svn: 328852
A short thunk uses a direct branch (b or b.w) instruction, and is used
when the target has the same thumbness as the thunk and is within
direct branch range (32MB for ARM, 16MB for Thumb-2). Reduces the
size of Chromium for Android's .text section by around 160KB.
Differential Revision: https://reviews.llvm.org/D44963
llvm-svn: 328846
There are two FPMs in an MSF file, the idea being that for
incremental updates you can write to the alternate one and then
atomically swap them on commit. LLVM defaulted to using FPM1
on the first commit, but this differs from Microsoft's behavior
which is to default to using FPM2 on the first commit. To
eliminate some byte-level file differences, this patch changes
LLVM's default to also be FPM2.
Additionally, LLVM was trying to be "smart" about marking FPM
pages allocated. In addition to marking every page belonging
to the alternate FPM as unallocated, LLVM also marked pages at
the end of the main FPM which were not needed as unallocated.
In order to match the behavior of Microsoft-generated PDBs, we
now always mark every FPM block as allocated, regardless of
whether it is in the main FPM or the alt FPM, and regardless of
whether or not it describes blocks which are actually in the file.
This has the side benefit of simplifying our code.
llvm-svn: 328812
The PLT retpoline support for X86 and X86_64 did not include the padding
when writing the header and entries. This issue was revealed when linker
scripts were used, as this disables the built-in behaviour of filling
the last page of executable segments with trap instructions. This
particular behaviour was hiding the missing padding.
Added retpoline tests with linker scripts.
Differential Revision: https://reviews.llvm.org/D44682
llvm-svn: 328777
This fixes pr36623.
The problem is that we have to parse versions out of names before LTO
so that LTO can use that information.
When we get the LTO produced .o files, we replace the previous symbols
with the LTO produced ones, but they still have @ in their names.
We could just trim the name directly, but calling parseSymbolVersion
to do it is simpler.
llvm-svn: 328738
This enables callback-style programming where the JavaScript environment
can call back into the Wasm environment using a function pointer
received from the module.
Differential Revision: https://reviews.llvm.org/D44427
llvm-svn: 328643
Some tools (dwarfdump for example) get confused by the current -O0 -r
output since it has multiple copies of .debug_str.
We cannot just merge sections with the same name as they can have
different sh_entsize.
We could have duplicated logic for merging sections based on name and
sh_entsize, but it seems better to just use the existing logic by
enabling optimizations.
llvm-svn: 328640
The Data member of synthetic section's is not valid and empty. The Data
member is required to be valid by ICF as it is used by ICF to determine
the equality of section contents. Therefore, exclude synthetic sections
from ICF.
Fixes bug PR36910.
Differential Revision: https://reviews.llvm.org/D44923
llvm-svn: 328624
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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 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
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
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
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
When you omit an argument, most options fall back to their defaults.
For example, --color-diagnostics is a synonym for --color-diagnostics=auto.
We don't have a way to specify the default choice for --build-id, so we
can't describe --build-id (without an argument) in that way.
This patch adds "fast" for the default build-id choice.
Differential Revision: https://reviews.llvm.org/D43032
llvm-svn: 324502
MIPS BFD linker puts _gp_disp symbol into DSO files and assigns zero
version definition index to it. This value means 'unversioned local
symbol' while _gp_disp is a section global symbol. We have to handle
this bug in the LLD because BFD linker is used for building MIPS
toolchain libraries.
Differential revision: https://reviews.llvm.org/D42486
llvm-svn: 324467
This is PR35740 which now crashes
because we remove unused synthetic sections incorrectly.
We can keep input section description and corresponding output
section live even if it must be empty and dead.
This results in a crash because SHF_LINK_ORDER handling code
tries to access first section which is nullptr in this case.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D42681
llvm-svn: 324463
Previously --defsym=foo2=etext+2 would produce incorrect value
for foo2 because expressions did not work correctly with
reserved symbols, section offset was calculated wrong for them.
Fixes PR35744.
Differential revision: https://reviews.llvm.org/D42911
llvm-svn: 324461
Previously we ignored -plugin-opt=mcpu=<xxx>
and the only way to set CPU string was to pass
-mllvm -mcpu=<xxx>
Though clang may pass it with use of plugin options:
-plugin-opt=mcpu=x86-64
Since we are trying to be compatible in command line
with gold plugin, seems we should support it too.
Differential revision: https://reviews.llvm.org/D42956
llvm-svn: 324459
In D42733 we supported different LTO command line
options, including -debugger-tune=<value>.
Initially debugger-tune support was needed to fix PR36035.
Patch adds testcase for this option to check we
don't simply ignore it.
Differential revision: https://reviews.llvm.org/D42961
llvm-svn: 324457
This is similar to _end (See https://linux.die.net/man/3/edata for more)
but using our own unique name since our use cases will most likely be
different and we want to keep our options open WRT to memory layout.
This change will allow is to remove the DataSize from the linking
metadata section which is currently being used by emscripten to derive
the end of the data.
Differential Revision: https://reviews.llvm.org/D42867
llvm-svn: 324443
objects, it confuses codegen into generating pc-rel relocations for those
symbols, which leads to linker errors.
Differential Revision: https://reviews.llvm.org/D42977
llvm-svn: 324435
In lld this was the only use of Config->Static where it meant anything
else other than "use .a instead of .so".
If a program turns out to not use any dynamic libraries, we should
produce the same result with and without -static.
llvm-svn: 324421
With fix:
Keep logic that ignores -plugin-opt=mcpu=x86-64 -plugin-opt=thinlto,
add checks for those to testcases.
Original commit message:
[ELF] - Use InitTargetOptionsFromCodeGenFlags/ParseCommandLineOptions for parsing LTO options.
gold plugin uses InitTargetOptionsFromCodeGenFlags +
ParseCommandLineOptions for parsing LTO options.
Patch do the same change for LLD.
Such change helps to avoid parsing/whitelisting LTO
plugin options again on linker side, what can help LLD
to automatically support new -plugin-opt=xxx options
passed.
Differential revision: https://reviews.llvm.org/D42733
llvm-svn: 324340
gold plugin uses InitTargetOptionsFromCodeGenFlags +
ParseCommandLineOptions for parsing LTO options.
Patch do the same change for LLD.
Such change helps to avoid parsing/whitelisting LTO
plugin options again on linker side, what can help LLD
to automatically support new -plugin-opt=xxx options
passed.
Differential revision: https://reviews.llvm.org/D42733
llvm-svn: 324322
Summary:
This patch adds some initial support for Windows control flow guard. At
the end of the day, the linker needs to synthesize a table of RVAs very
similar to the structured exception handler table (/safeseh).
Both /safeseh and /guard:cf take sections of symbol table indices
(.sxdata and .gfids$y) and turn them into RVA tables referenced by the
load config struct in the CRT through special symbols.
Reviewers: ruiu, amccarth
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42592
llvm-svn: 324306
When using Elf_Rela every tool should use the addend in the
relocation.
We have --apply-dynamic-relocs to work around bugs in tools that don't
do that.
The default value of --apply-dynamic-relocs should be false to make
sure these bugs are more easily found in the future.
llvm-svn: 324264
When resolving dynamic RELA relocations the addend is taken from the
relocation and not the place being relocated. Accordingly lld does not
write the addend field to the place like it would for a REL relocation.
Unfortunately there is some system software, in particlar dynamic loaders
such as Bionic's linker64 that use the value of the place prior to
relocation to find the offset that they have been loaded at. Both gold
and bfd control this behavior with the --[no-]apply-dynamic-relocs option.
This change implements the option and defaults it to true for compatibility
with gold and bfd.
Differential Revision: https://reviews.llvm.org/D42797
llvm-svn: 324221
We did not report valid filename for duplicate symbol error when
symbol came from binary input file.
Patch fixes it.
Differential revision: https://reviews.llvm.org/D42635
llvm-svn: 324217
Initially LLD generates Elf_Rel relocations for O32 ABI and Elf_Rela
relocations for N32 / N64 ABIs. In other words, format of input and
output relocations was always the same. Now LLD generates all output
relocations using Elf_Rel format only. It conforms to ABIs requirement.
The patch suggested by Alexander Richardson.
llvm-svn: 324064
--nopie was a typo. GNU gold doesn't recognize it. It is also
inconsistent with other options that have --foo and --no-foo.
Differential Revision: https://reviews.llvm.org/D42825
llvm-svn: 324043
In GNU linkers, the last semicolon is optional. We can't link libstdc++
with lld because of that difference.
Differential Revision: https://reviews.llvm.org/D42820
llvm-svn: 324036
Currently ICF information is output through stderr if the "--verbose"
flag is used. This differs to Gold for example, which uses an explicit
flag to output this to stdout. This commit adds the
"--print-icf-sections" and "--no-print-icf-sections" flags and changes
the output message format for clarity and consistency with
"--print-gc-sections". These messages are still output to stderr if
using the verbose flag. However to avoid intermingled message output to
console, this will not occur when the "--print-icf-sections" flag is
used.
Existing tests have been modified to expect the new message format from
stderr.
Patch by Owen Reynolds.
Differential Revision: https://reviews.llvm.org/D42375
Reviewers: ruiu, rafael
Reviewed by:
llvm-svn: 323976
Don't include type signatures that are not referenced by
some relocation.
We don't include this in the -gc-sections settings since
we are always building the type section from scratch,
just like we do the table elements.
In the future we might want to unify the relocation
processing which is currently done once for gc-sections
and then again for building the sympathetic type and
table sections.
Differential Revision: https://reviews.llvm.org/D42747
llvm-svn: 323931
Summary:
r323164 made lld-link not overwrite import libraries when their
contents haven't changed. MSVC's link.exe does this only when
performing incremental linking. This change makes lld-link's import
library overwriting similarly dependent on whether or not incremental
linking is being performed. This is controlled by the /incremental or
/incremental:no options. In addition, /opt:icf, /opt:ref, and /order
turn off /incremental and issue a warning if /incremental was
specified on the command line.
Reviewers: rnk, ruiu, zturner
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42716
llvm-svn: 323930
Summary: Instead of fatal-ing out when missing a type server PDB, insead warn and cache the miss.
Reviewers: rnk, zturner
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42188
llvm-svn: 323893
Summary:
While trying to make a linker script behave the same way with lld as it did
with bfd, I discovered that lld currently doesn't diagnose overlapping
output sections. I was getting very strange runtime failures which I
tracked down to overlapping sections in the resulting binary. When linking
with ld.bfd overlapping output sections are an error unless
--noinhibit-exec is passed and I believe lld should behave the same way
here to avoid surprising crashes at runtime.
The patch also uncovered an errors in the tests: arm-thumb-interwork-thunk
was creating a binary where .got.plt was placed at an address overlapping
with .got.
Reviewers: ruiu, grimar, rafael
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D41046
llvm-svn: 323856
When there is a duplicate absolute symbol, LLD reports <internal>
instead of known object file name currently.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D42636
llvm-svn: 323849
In this initial version we only GC symbols with `hidden` visibility since
other symbols we export to the embedder.
We could potentially modify this the future and only use symbols
explicitly passed via `--export` as GC roots.
This version of the code only does GC of data and code. GC for the
types section is coming soon.
Differential Revision: https://reviews.llvm.org/D42511
llvm-svn: 323842
Add a simple start entry point input file and have the tests
reference that rather than duplicating these.
This allows more tests to be pure `.test` files rather than
`.ll`.
Differential Revision: https://reviews.llvm.org/D42662
llvm-svn: 323838
Previously an empty CPU string was passed to the LTO engine which
resulted in a generic CPU for which certain features like NOPL were
disabled. This fixes that.
Patch by Pratik Bhatu!
llvm-svn: 323801
Currently symbols assigned or created by linkerscript are not processed early
enough. As a result it is not possible to version them or assign any other flags/properties.
Patch creates Defined symbols for -defsym and linkerscript symbols early,
so that issue from above can be addressed.
It is based on Rafael Espindola's version of D38239 patch.
Fixes PR34121.
Differential revision: https://reviews.llvm.org/D41987
llvm-svn: 323729
I didn't implement the feature in the original patch because I didn't
come up with an idea to do that easily and efficiently. Turned out that
that is actually easy to implement.
In this patch, we collect comdat sections before gc is run and warn on
nonexistent symbols in an order file.
Differential Revision: https://reviews.llvm.org/D42658
llvm-svn: 323699
This should fix PR36017.
The root problem is that we were creating a PT_LOAD just for the
header. That was technically valid, but inconvenient: we should not be
making the ELF discontinuous.
The solution is to allow a section with LMAExpr to be added to a
PT_LOAD if that PT_LOAD doesn't already have a LMAExpr.
llvm-svn: 323625
Patch adds one more module with non-prevailing
version of asm symbol, defined in main module
This is for D42107, which is under review.
Extended version of testcase would fail with the
diff 9 version of patch posted.
llvm-svn: 323584
With the /order option, you can give an order file. An order file
contains symbol names, one per line, and the linker places comdat
sections in that given order. The option is used often to optimize
an output binary for (in particular, startup) speed by improving
locality.
Differential Revision: https://reviews.llvm.org/D42598
llvm-svn: 323579
This fixes the crash reported at PR36083.
The issue is that we were trying to put all the sections in the same
PT_LOAD and crashing trying to write past the end of the file.
This also adds accounting for used space in LMARegion, without it all
3 PT_LOADs would have the same physical address.
llvm-svn: 323449
Previously, we were ensuring that the "output index" for
InputFunctions was unique across all symbols that referenced
a function body, but allowing the same function body to have
multiple table indexes.
Now, we use the same mechanism for table indexes as we already
do for output indexes, ensuring that each InputFunction is only
placed in the table once.
This makes the LLD output table denser and smaller, but should
not change the behaviour.
Note that we still need the `Symbol::TableIndex` member, to
store the table index for function Symbols that don't have an
InputFunction, i.e. for address-taken imports.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42476
llvm-svn: 323379
Previously llvm was using 0 as the first table index for wasm object
files but now that has switched to 1 we can have the output of lld
do the same and simplify the code.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42096
llvm-svn: 323378
Rui Ueyama